Using beta:
Using beta:
Long pressing on an app item brings up the edit menu and then you have to long press again to be able to select actions or edit the icon or text. I feel it would be much better to have the actions menu show by default and have an edit item option in that menu that opens up the edit mode.
The actions menu is what you would expect to appear when you long press on an app in any other launcher. Most of the time I want to view the item in the play store or uninstall it but have to go through three menus or find it manually in the app which is just tedious. Of course if edit mode is active and the app item is long pressed it would be natural to assume the menu would be shown as it is currently.
]]>
D5 Creation
< ![CDATA[
And I must add: if you have auto-edit mode disabled it is worst, because you can’t actually open the menu unless you go into edit mode.
]]>
< ![CDATA[
Hum… I recently disabled this menu on initial long press because I wasn’t satisfied with the current behavior (it is somewhat conflicting with edit bars). But I understand that no menu at all is not better, and maybe worst, yes.
I am worried about displaying only the content of the “Actions” sub menu though. The reason is that everybody has different goals and I would prefer to show the full menu even if this means an extra click to reach the actions (that I use a lot myself to tell the truth).
What about changing the default long tap action to “Item menu”, and in this menu add at the bottom “Edit layout”. This way it would not enter edit mode, most options would still be there, even with an extra tap, and it would be possible to switch to edit mode reasonably fast too.
]]>
< ![CDATA[
Pierre Hébert Personally I would have the menu show the actions menu as well as a customize item button and edit layout button at the bottom. That covers pretty much everything the user would want to do with an app link.
The way I see it, there are two situations a user would be in when long pressing an app: wanting to alter the app itself and wanting to edit the LL settings for the link. The current menu is perfect for the editing but not for day to day app management. That’s why I feel the current menu should be displayed in edit mode yet the one suggested in the previous paragraph should be displayed when not in edit mode. This exposes the most useful controls for the current situation while still providing access to the others.
]]>
< ![CDATA[
I also prefer it to show the full menu when not in edit mode, as it was before.
Just thinking: previously when you long clicked an item you could move it to another position. Then, if you had the auto-edit checked or not, the edit mode was automatically cancelled or not.
Now it is a problem, because the desktop is shifted.
What about:
If you are in edit mode and you long click an item, all as now.
But
If you are not in edit mode and you long click an item, show the menu, and leave the user to move it as it was before entering edit mode with the hidden bars (Only showing the arrow in the corner)
Then, if you had the auto-edit unchecked, the only change will be that the arrow will disappear. And if you had it checked you can either leave it hidden, or show the bars automatically when the item is no longer tapped.
]]>
< ![CDATA[
I definitely think there needs to be a divide between standard use and editing. I don’t think any LL related setting should be changeable unless the user enters the edit mode (the bars slide out) or they access a LL settings menu.
Every menu seems fine as it is for the edit mode but here is what I would use for long press menus in standard mode. Items marked with an asterisk (*) open edit mode. Settings menu has: (bracket items below), Current Desktop, Lightning Launcher, and Android settings buttons.
Panels and other containers have:
Add Item*
Settings (Panel Settings)
Edit panel*
Delete panel*
Widgets have:
Settings (Launch app)
Play Store
Kill
Uninstall
Edit widget*
Delete widget*
Apps/shortcuts etc:
Settings (Info)
Play Store
Kill
Uninstall
Edit item*
Delete item*
It keeps the more common LL settings available but hides the advanced options while providing a more useful set of day to day options.
This change should make every day use more fluid and easy. More importantly it would perform more like other launchers which if we are honest has been a major issue with the launcher. It is a brilliant launcher but does overwhelm the user with options and have a steeper learning curve than most.
The current changes you are making seem to be taking it in the right direction: moving it away from an enthusiasts modding tool to a professional, easy to use, mass market piece of software. It just needs that extra bit of UI optimization which usually comes from a research/testing team.
]]>
< ![CDATA[
Great, we all agree on the behavior when already in edit mode 🙂
Now regarding what happens when not in edit mode, I believe that there is too much granularity in what can be configured using the long tap event. There are several actions related with the item edition (move item, edit layout, item menu, auto edit) and something has to be cleaned up, definitely. I wonder whether all these settings are really useful. This partly comes from the fact that in the past Lightning was trying to mimic some more traditional launcher behavior, the wrong way.
Entering the edit mode with bars initially hidden (and displaying them once the item is released?) is certainly a good starting point.
Having different menu goals when editing or not make sense. I agree there are two distinct modes: use and edit. That’s a difference with “basic” launchers (basic is not an insult here) where everything is combined seamlessly.
I need to digest all these things during the night…
]]>
< ![CDATA[
Pierre Hébert Well you have my thoughts on the menu contents. 😛 I’m sure whatever you do will be good.
]]>
< ![CDATA[
Pierre Hébert Or maybe…. Set some defaults, then in LL general settings, give the ability to choose what to put on the long press menu, depending on the context!
And for crazy ones, give an api to be able to script that menu content! ^^ (“soyons fou”: with custom entries!!)
]]>
< ![CDATA[
James Coyle on a side note I doubt that Lighting will ever be ready for mass market.
Benoît de Chezelles that’s on the TODO list somewhere, lol. There’s also a custom menu that you can populate with scripts. It can be used as a replacement of the builtin menu for most things (but not all).
]]>
< ![CDATA[
I had some time to think at this discussion and you convinced me James Coyle.
This menu will have a different content when not in edit mode, and in addition I will introduce an horizontal bar at the top of this menu with 3 icons button for fast access to most common edit actions. For item: edit / clone / delete, for container: edit / add / settings. It will have several benefits: it will shorten the menu, separate edit actions of “management” actions and add a bit of eye candy (maybe, lol). These icons will replicate those found in the edit bars.
With the edit button and the edit bars, the other edit functions are not too far away.
This is a disruptive change but I guess this is the right time to do it!
]]>