[MGNLUI-2846] Rearrange the Apps screen to better demonstrate the idea of content pools / apps Created: 29/Apr/14 Updated: 09/Mar/21 Resolved: 09/Mar/21 |
|
| Status: | Closed |
| Project: | Magnolia UI |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | New Feature | Priority: | Neutral |
| Reporter: | Andreas Weder | Assignee: | Unassigned |
| Resolution: | Obsolete | Votes: | 0 |
| Labels: | ux | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Attachments: |
|
||||||||
| Issue Links: |
|
||||||||
| Template: |
|
||||||||
| Acceptance criteria: |
Empty
|
||||||||
| Date of First Response: | |||||||||
| Description |
|
I've discussed some changes to the Apps screen with Pascal lately. One thing we'd like to see is a clearer distinction between apps for editing content (typically content apps) and apps that publish such content. More specifically, I propose we change the Apps screen in two steps to realize this idea:
The attached, two screenshots show both steps. We originally wanted to introduce such a change with 5.3, but the feedback I got was consistently sceptical to right out negative. The distinction between "page" and "non page" apps seems to feel too artificial still. I've thus decided to split this idea off the rest of the changes (mentioned in My gut feeling also tells me that especially the second change would be best done once we add "virtual trees" to represent sites. |
| Comments |
| Comment by Richard Unger [ 29/Apr/14 ] |
|
I don't know if this is the right place, but I'd like to give some feedback on this: 1) please enable custom icons for apps. Icon-Font is a nice optimization, but since adding new icons to the font will be a longer process, in the meantime developers should be able to have custom icons on their apps just by using a PNG or SVG image. 2) While I understand your paradigm of "content apps" vs. "assembly apps", this is **not at all** how our users (editors) work, or think about the content. 3) Please leave the layout as it is until you arrive at a final solution for the applauncher layout. Please don't release the interim solutions. When the buttons move around this is very irritating for the users, who rapidly 'learn' the button positions and find it very disruptive when they are moved. |
| Comment by Andreas Weder [ 29/Apr/14 ] |
|
Hi Richard, thanks for your feedback. 1) We're aware of this limitation and have some ideas how to solve this. The plan was to get this into 5.3 still, but I'm actually unsure where we stand there. 2) That's exactly why I've split this (what I consider: delicate) topic off the changes I've described in For users working mainly in Pages, I agree that what I call "in-place editing" (editing of content managed by another app without leaving the app you're currently in) is an essential feature. It has been brought up more and more frequently recently. I'd like to see this added to our framework rather sooner than later, but it's not a quickwin. Nevertheless, this is an important part of the original interaction concept and prevents "app thrashing", the repetitive and disruptive switching between two apps to solve a task. There is another group of users though, which do not work in Pages most of the time, but fill in content in dedicated apps, with a "managing editor" taking care of publishing that content on actual web pages. We'll have to accomodate both user groups. I'm pretty sure, though, that our current plans and ideas will be able handle that. And since the Apps screen is easily configurable, you can also always come up with a set up that suits your users better than the default set up coming with the product. 3) The changes in |