Suggestion #9049
Pagetree redesign worries
| Status: | Accepted | Start date: | 2010-07-27 | |
|---|---|---|---|---|
| Priority: | Should have | Due date: | ||
| Assignee: | Lars Zimmermann | % Done: | 0% |
|
| Category: | Interface | |||
| Target version: | - | |||
| Tags: | ||||
| Votes: | 0 |
Description
- document type
- hidden status
- hidden in menu status
- fe user restriction status
- inherit to subpages
- ... (list goes on and on)
It seems that the UX/design team has decided to express the information about the statuses which can be passed to child records as the colour of the dotted lines between the elements in the tree. Using only colour as information is simply wrong for obvious reasons (a significant part of the population has problems with colour vision).
The screenshot (yes, older version of TYPO3, but information overload is still the same) of a real website shows that for some pages overlay information is already lost and the base icon is virtually invisible.
There are a lot of ways to move the information around (a less 'visible' status area next to the main icon, line types (dotted, dashed, solid, etc.) between elements, icons on/near lines between elements, etc.) but these do not solve the information overload problem.
Maybe in the extJS version of the pagetree a "tree-grid" element can be used? The extra information can be displayed in a column on the right hand side of the tree. The column(s) can be hidden/shown if the BE user needs the information (often a BE user only needs to navigate in the tree).
Other solutions should at least make sure that:- less information is displayed by default (information overload)
- information can be made visible for the entire tree (the opened branches) to have an overview
- information must be easily recognizable (not only colour, easy to understand icons, etc.)
History
Updated by Jens Hoffmann almost 3 years ago
I will try to write more. For now this is the Protocol of our last Meeting.
There we discussed this topic. I think we found a good solution for this.
http://forge.typo3.org/projects/hci/wiki/T3Skin_Meeting-20100716#Icons
Wait until we provide Screen to judge the ideas/plans, please.
Updated by Jigal van Hemert almost 3 years ago
Thank you for your reply.
Unfortunately the descriptions of some of the ideas/plans are so clear that screen shots are not necessary to understand the consequences:
- Only one Overlay will be shown at a time
This is almost worse than showing all overlays. Imagine three pages, on with property X, one with X,Y and one with X,Y,Z; priority for overlay display is Z,Y,X. Now you will see one page with overlay X, one with Y and one with Z. Does this help? No, removing all overlays will be better because you're forced to use the Rollover information.
- Access Restricted Overlays will be 2 colored
- Recursive Action get colored Pagetree lines
Both: information expressed by colour alone is pretty bad.
- Editor Icon in the Pagetree Blinks (gif?)
Sometimes it's best to start fresh, instead of tweaking an existing thing to death... (but that's only an opinion)
Updated by Jens Hoffmann over 2 years ago
What would be your suggestion/solution?
Updated by Jigal van Hemert over 2 years ago
First of all, there is a rather different demand by "normal" BE users and power users such as admins. Most "normal" BE users express that they find the amount of information in the BE overwhelming, so they need a simple interface. Power users want direct access to all possible options. I try to make suggestions for both groups.
Regarding the remarks in the T3Skin Meeting 2010.07.16 some remarks based on feedback by BE users:
- All Page Addons (Shortcut, Link, Mountpoint) get switched to „real“ full icons, without page.
Good that the icons represent the type of "page". Only extra information for "normal" BE users would be: hidden status and the type of records in a sys_folder (tt_news records, media folder, etc.).
- All Overlays are placed at the Bottom Right
- Only one Overlay will be shown at a time
o All other Icons will be shown on Rollover with actual values
For "normal" users a block with the other status information which is currently in the overlays on rollover would be great. Easy to see the properties of a page without opening the page properties dialogue and no information overflow in pagetree.
Power users like a lot of information. Maybe they can set an option to display all the status information in an extra block at the right side of the page tree? Then it's easy to see which pages have which settings.
Only one overlay is actually worse than the current situation. With one overlay only some information is shown and other information is hidden. For most people it's hard to understand that when only two pages have status "x" and one has status "y" the status "x" of the second page is not shown because the other status has priority. It's confusing when information is shown seemingly arbitrarily (the knowledge of the priority list is easily forgotten).
- Access Restricted Overlays will be 2 colored
o Color 1 = Frontend
o Color 2 = Backend (Backend user Section)
Since a large portion of the population has some problems with colour vision information should not rely on colour alone.
- Recursive Action get colored Pagetree lines
o The Icon with the major Option will keep the Icon
Again, information should not rely on colour alone. Recursive action is probably that settings are inherited from higher levels. In such a case the page has the setting, but in some way it should be indicated that the setting was not made on that page but on a higher level. Why not show the setting icon with an "inherited" ("recursive") overlay (or indicator)?
- Editor Icon in the Pagetree Blinks (gif?)
Blinking was suggested as a joke during the development of Netscape. It was always considered to be "not done". Blinking in graphics is rather late 1980s (the age of the animated gifs).
The remarks above are merely suggestions based on personal opinions and feedback of BE users.
Updated by Jens Hoffmann over 2 years ago
Hy,
thanks that you gave me feedback to our Protocol :) I also hoped to get some new ideas to solve the issues.
Most things you are suggesting, are somehow like we have them now - and right now it's really not a good solution.
And it seems to me like this Protocol is more an Internal Protocol which is not 100% well understandable for persons
who didn't attended that Meeting.
First of all the stuff out of the Protocol is already deiced by the Team.
But we are always open for new innovative ideas. But not a return what we have right now, sorry.
- It's not important to create the context in most cases, the context is already clear
- The Page is just the context and takes to match space for the actual message
- That is why we use only the "Link" icon instead the "Page+Link" Icon
- We created a hierarchy and based on this, only the most important Icon will be added
- The overlay will even show the values .. this is what we don't have right now.
- We just refreshing the colors .. no point to argue there
- We need to visualize this via the Page-tree connections (With a different Line&Color style)
- To use a GIF which is able to visualizes/communicate a current processes action is not a joke!
- It's nice that those principle like that even work since 1980 ... STOP BASHING!
Don't get me wrong, please. Nothing is mean to be personal! I really like to get inspired by new Ideas. :)
Updated by Jigal van Hemert over 2 years ago
- File pagetree_suggestion.png added
Most things you are suggesting, are somehow like we have them now - and right now it's really not a good solution.
No, I'd like to get things a lot simpler for "normal" users and a lot clearer for "power users".
In the image I added I made some crude versions of the ideas.
1. The Icons need to be clearer!
Absolutely. You have good ideas to make them clearer, especially by leaving out the unimportant parts.
2. There are 5 possible Overlays
- We created a hierarchy and based on this, only the most important Icon will be added
- The overlay will even show the values .. this is what we don't have right now.
To simplify it even more for "normal" BE users, I propose to use no overlays. We have too much information to show in overlays, so the icon itself is currently invisible on some pages. Showing only the most important overlay is confusing; it hides important information, because on that particular page other information was considered more important because some magic hierarchy list decided so. If a BE user is looking for a certain property of a particular page he/she may not see that property because sometimes the system decided it was not important to show.
- if the system shows that a page has group access settings, it may also have time restrictions but that information is not shown (exact hierarchy not known by me, just an example)
- if two pages have group access settings, only one may show it because for some unknown reason (the hierarchy is not know to most users) another property is shown on that page
In my example I show all information in a special "callout" / "popup" / panel. Because no properties are shown there is no confusion. To see the properties the user must hover over the icon and then all properties are shown.
For "power users" it's possible to activate a separate column which shows all properties. No information is lost.
3. Colors for Front-/Back-end are used since 3.x
- We just refreshing the colors .. no point to argue there
No arguing about colour changes, just the remark that information should not rely on colour alone. So if there are two icons which differ only in colour this time is the chance to slightly redesign one of them to make it different in other ways than just colour.
4. Right now you can see which child's are depending on a recursive change
- We need to visualize this via the Page-tree connections (With a different Line&Color style)
In my example I have no overlays on 'page' icons and I show full size icons for properties. So it's possible to use an overlay on a property icon to indicate that it is there because that page inherited the property from a higher level. You can easily follow the levels in the page tree to find the same icon without the overlay.
5. Blinking GIF != Blink Tag
- To use a GIF which is able to visualizes/communicate a current processes action is not a joke!
For a "loading" animation it's good. It will stop once the action is done. The user-X-started-edition-this-page-n-minutes-ago icon represents a state (just like the blinking "currently selected page" icon in the page link popup). I'm sure there is an eye catching visual styling possible without blinking.
- It's nice that those principle like that even work since 1980 ... STOP BASHING!
It's not about bashing, but to me a blinking icon looks both old fashioned and cheap. It doesn't fit the fresh, modern look of versions 4.4/4.5 and later.
The attached image is just a quick sketch to illustrate an idea. Maybe it triggers creative solutions :-)
Updated by Lars Zimmermann over 2 years ago
- Category set to Interface
- Status changed from New to Accepted
- Assignee set to Lars Zimmermann
- Target version set to TYPO3 4.5 LTS
Hey guys,
I've read with big interest you're discussion and I see the point in both of you're opinions. I think the time of discussing things via complicated descriptions has to go a step further (as Jigal did perfectly) by providing visuals for new ideas. I will create a new tree version as the HCI decided at the last meeting with the protocol.
@Jens: Can you provide wireframes for the things you scribbled onto the whiteboard and photographed with your iPhone?
After doing this I will post the screens here and we & Jigal can have a look at the original ideas of the HCI team. Than we can go into a second round of shaping even better ideas into it. I think this a better basis for discussion. Do you agree with me?
cheers
lars
Updated by Jigal van Hemert over 2 years ago
Any news here? RCs are getting closer...
Updated by Jens Hoffmann 6 months ago
- Target version deleted (
TYPO3 4.5 LTS)