[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: PNG File App screen changes.Step 1.png     PNG File App screen changes.Step 2.png    
Issue Links:
relation
is related to MGNLUI-2843 Rearrange the Apps screen to emphasiz... Closed
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:

  1. Add example content apps for "News", "Products", maybe "Events", while still keeping the "Contacts" apps. The content of these apps must be used by the demo project in order to unleash its full potential.
  2. Assemble content apps under the "Edit" group and add a second group (e.g. "Site" or "Gather/Collect/Assemble") for assembling such content on "Pages" using "Assets".

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 MGNLUI-2843) and only introduce them once we have a clearer idea about and an explicit focus on content pools and content apps in one of the releases following 5.3.

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.
They want to use the pages app, and only the pages app. They never want to switch between apps when editing.
They are unable to make complicated associations between seperate trees, and it is very difficult for them to "find" content for including in another app. They want to work "inside the design", using pickers to choose content for including (like assets). They want to create new content (assets, contacts, categories) right from inside the pages app.
So it is not a matter of creating many editing apps used by a few assembly apps, it is a matter of all apps being tied into the pages app via pickers, "new content" dialogs and "upload dialogs".
(--> we have an existing support-request on this topic: making the asset upload from the pages app show the asset fields to the editor. That's the way our editors think.)

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 MGNLUI-2843: my observations so far let me doubt this actually works for users. I've deliberately not set a fix version on this issue to not get this done until we know what we need.

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 MGNLUI-2843 mainly affect the new apps your users don't know yet, or they affect apps like "Contacts". The latter actually confuses customers quite some, which see it as some kind of "address book" or as an app replacing their directory server, whereas it's actually just a sample of how to deal with content outside of pages.

Generated at Mon Feb 12 09:00:44 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.