Hi,
I am agree with all your ideas.
We have already talk about changing the tabs position. But, I think that
the position must be always the same and that the position change should
be thought about a redesign and a complete reflection at the interface
of GLPI.
The idea of categorizing tabs is very good I think. We need to study it
and find a technical solution to be able to do it (but maybe not in the
next version).
Find a solution to have less scroll is really complex for me because I
think that standard informations are usefull with several tabs. Maybe
splitting common informations and advanced informations may be a
solution to limit the size of the main form.
Regards
Julien
Le 14/05/2011 21:29, Fabrice Flore-Thebault a écrit :
Le vendredi 13 mai 2011 16:56:40, MoYo a écrit :
Hi,
Hi,
I am working on displaying count of items in tabs. You could test the
unstable version for view it.
This raises a trouble : we have tabs with several contents.
Examples :
- Connexions one which include direct connexion and network port connexion.
- Management : include contracts and administratives informations.
A solution will be to split them but we will have lots of tabs.
Do you think it will be a problem on browsing / working ?
Some ideas about the tabs that i would like to share :
1. Less tabs is more understandable :
I think there is already too much tabs. More than 5 tabs make the application
less usable.
We should keep in mind that the human brain can keep in memory between 4 and 7
items. When you have a longer list of items, there is much more work too make
it understandable.
As exemple of good usage of the tabs i appreciate that the main tabs setup has
6-7 tabs (depending on presence of plugins).
I liked a lot the work we did with the configuration menus for 0.78,
decreasing the number of tabs from 10+ to 5.
I would like to convince you to continue this way, and prefer decrease or
reorganization of tabs to addition of tabs.
2. For long lists of items, "bullet list" type of display (vertical) is IMHO
far more readeable than tabs (horizontal).
The "bullet list" display is the most commonly used display in rich
applications like CRMs, ERPs, Groupwares when they have long lists
example of bullet list :
- AAAA AAA AAA
- BBBBBBBBBBBBB
- CCCCCCC
- DDDDDDDDD
- EEEE EEEEEEEEEE
- FFFFFFFFFFFFF FFFF
- GGGGG GGGG GGGGGG GGGG
same example displayed as tabs feels less readable to me :
AAAA AAA AAA ; BBBBBBBBBBBBB ; CCCCCCC ; DDDDDDDDD ; EEEE EEEEEEEEEE ;
FFFFFFFFFFFFF FFFF ; GGGGG GGGG GGGGGG GGGG
Firefox, wich is the software who made tabs the most common, has now options
to collapse tabs, as too much tabs is just unusable.
I would like to convince you that, when we have more than 5 tabs, vertical
display should be preferred.
3. Categorize ?
Without any plugins, for a computer we have now 12 tabs, which is already much
too much. The fact that every plugin is adding hist own tab makes in just
awfull at the end.
Maybe it could be a good idea to group tabs in few categories (visible like
the main menu), with subcategories and let plugins add their "tab" in a
subcategory.
For example :
- Inventory :
- components
- volumes
- connexions
- software
- virtual machines
- Administrativia :
- management
- documents
- notes
- Lifecycle :
- tickets
- links
- booking
4. Less scroll
For now, for computers, every tab is starting with the same information : the
avalanche of information about the computer, that you can collapse with the
citroën sign. When not collapsed, this information is already using all the
available space on the screen, even on a reasonable size of screen. This makes
useless the usage of tabs, which as i understand, were added to avoid
scrolling. I would suggest either to collapse this info by default, or to
display it only on the first tab.
The work in progress will make possible to implement a system to set the
tab order. Maybe for the next version or later.
Could be great also, but IMHO the organization in categories should be tried
first.
As always, i have no idea if it's possible to implement of all these ideas in
a reasonable amount of time, but i would like to convince you this would be
great fo glpi.
Cheers,
_______________________________________________
Glpi-dev mailing list
Glpi-dev@gna.org
https://mail.gna.org/listinfo/glpi-dev
