Suggestions/comments about the new hierarchical menu:
1) Desktops doesn’t follow formatting convention “Desktop ‘name’: #00000” instead of “Type ‘name’ (#0000)”
2) When opening it from the items/hierarchy open it in the item/container. When opening it from the edit bar open it where it was previously (current behavior)
3) Narrower icons, less space between them and less right margin (the edit and options icons I mean) maybe also add a disabled edit icon for desktops, so same icons are all aligned. (Or instead make it to open the ‘manage desktops’ screen? )
4) Instead of tabbing, use a different ‘inside container’ indicative, for example this simple but effective one: (characters ┃U+2503 ┗U-2517 ┣U-2523)
Desktop
┣ Item
┣ Folder (opened)
┃┣ Item
┃┗ Item
┣Item
┣Folder (closed)
┗Item
5) Not sure about this but: invert the z-order sorting so that top most item is placed upper in the list? Hmm, with this configuration it should be better to have the ‘items inside a container’ placed above the container item…hmm. Setting to choose between one or another? 😛 ok, maybe better leave it as it is now.
]]>
D5 Creation
< ![CDATA[
Wait what have I missed? New beta?
]]>
< ![CDATA[
Do you read my posts before Pierre’s ones?
Well, that’s…good (for me)…I guess O.o
]]>
< ![CDATA[
Thanks for your suggestions, I am opening a flySpray task where I will gather most hierarchy screen related ideas.
Regarding 2 I am trying to find the best way to highlight the selected item or container, but while thinking at that I was also thinking that maybe the hierarchy screen could have normal and edit modes too. It would follow the current layout edit mode. Not sure that this would be so useful though.
I tried these special characters for indentation but this doesn’t look good. I need to either tweak sizes and margins so that there is no gap between list items, or build custom drawings, or a custom view.
I prefer not to reverse the items order. I understand that on one hand it is a more natural representation of the stacking, but on the other hand this is really unusual.
]]>
< ![CDATA[
I prefer it with only one mode (the edit one) where long tapping is for moving items (also Danbar’s suggestion so if you long tap and release on the same spot, the full name is shown on a toast)
Oh, one thing more I forgot. If you want to move an item inside a container you need to open it before starting to drag the item. What if it is automatically opened when hovering the item above the container?
Hmm, I also found another bug: if you move an item to the end of the list of a container’s items, it is placed one level before, I mean in the parent of the container, instead of inside the container
]]>
< ![CDATA[
About my last comment: there is the problem about ‘the user dropped the item at the end of the list, did they want to place it inside the folder or outside?’
What about a ‘line’ entry that you can’t drag, indicating the end of a opened container? This way moving the item above or below this line will mean where do you want it to be
]]>
< ![CDATA[
I cannot easily achieve automatic container opening because it needs to update the adapter, and updating the adapter has for effect to reset transient drag data.
Regarding the last element I designed it this way since this is indeed ambiguous. I am not sure I can add a separator entry, but this is a good idea, I will try.
]]>