maemo.org - Talk - [Announce] ApMeFo (beta 0.9-5) - Create custom folders in your Application Menu

Quote:

Horizontal tab bar translates poorly to mobile applications, especially in landscape view. If a tab bar is really necessary (it's not), it should at least be vertical.

Not sure I agree at all. Perhaps I'm not getting what you mean, but that seems like an entirely personal-preference matter.

Quote:

[Text Box] [Select] is fairly awkward for choosing whether to edit or create a new folder.

Fair enough. I'd agree with that. Rather, to me it's not awkward, but it could certainly be improved.

Quote:

[Text Box] [Select] is really awkward for choosing an icon. It's unlikely I'll be able to choose an icon by just typing in a name, even if I'm going off of memory. And using text to describe the icon takes up more space than just showing the icon.

I disagree there. It is only awkward for the first few minutes if you're not used to seeing other programs with similar conventions, and have to figure out that you should click the select button and the box is the name. Once you press the select button, it's vey intuitive, because it's just a list of the pictures. Can't really get more intuitive than that.

Furthermore, space? We don't really have an issue of space in the ui as is. Also, just because most people don't want or can't use the icon paths and names automatically, doesn't mean just having the option is bad. Some people do have enough experience fiddling with the file system or just looking around in there to be able to use the text box, because maybe they DO remember the name of the icon. But I DO like the idea of showing the picture of the icon, and I say that should be implemented. What I would suggest to / request from Hrw is that if you add the picture, (say, where the text box is now), put the textbox under it - ideally made to show the path of the file instead of just the name (does the current ApMeFo have the ability to use icons from anywhere, or does it have to be one folder - I'm not knowledgable how the underlying code works).

That said, as it is right now, so long as the list still shows the name of the icon, I suppose having the icon itself shown instead of its file name would be an improvement. Though I recommend both (and if I had the coding experience to do it, I would, but there I am lacking).

Quote:

[Text Box] [Select] is really awkward for choosing a folder to delete, because I can't even use the text box.

Eh, the box is grayed out. I thought it was pretty self apparent. Also, it gives you an extra layer of certainty that you selcted the right thing. There were plenty of times when I could've sworn I selected an icon from the list, only to find out I accidentally selected something else right next to it, or had it glitch and select an entirely unrelated icon. With icons this is fine becuase you can see the name of it, or (as proposed) the picture or both. But with folders if you don't have that box there you don't really have a way to see what you're deleting.

Quote:

Selecting an icon is somewhat difficult, due to the large number of icons to choose from. A grid of icons would be preferable to icon - name list

I agree, but if this is implemented, I think it makes having the text box in the above point for icon selection when editing/creating folders all the more necessary. Granted, not literally necessary, but I think having at least one place that tells you what the file name of the image you're using is is a pretty good feature to have. I don't really see how it impedes intuitiveness at all, or usability, especially when you have the select buttons, especially with the above suggested changes. I think there's enough use cases when someone might want to know the name or path of the icon file without knowing enough about where to find the relevant directories or .menu/.desktop config files to make completely cutting out the icon filename from the UI unjustified. But, if I had to pick, I'd say leave it in the folder editing creating menu and implement the grid of icons you recommend for icon selection. (though the question is how easy IS icon grid implementation in this UI? It may just be to ridiculous of a coding pain in the anal region.)

Quote:

Having separate buttons to actually create/edit/delete/update folders after already selecting a folder to create/edit/delete/update is redundant. If the UI is intuitive, there shouldn't be any need to confirm that I actually want to do what I was trying to do. (As for preventing accidental deletion, that would be better served by a popup warning if the selected folder contains apps)

I think this has to do with how the app works. It has to first select the right .menu and/or .desktop (not sure what the details are) file to make the changes to. But, this should be automatable and I agree, there is a certain redundancy to it. I never minded, but I probably wouldn't mind any other alternative. though, on second thought, some of it makes perfect sense. someone might be mid updating their folder (therein being the first 'selecting'), shuffling a bunch of stuff around, then decide they don't want to keep the changes, or want to make a different set of changes, but starting over from what they had would be more effective then moving/adding/deleting apps to get there from where they are now. Is it really better to have every change saved as you make it to the folder you're updating instead of having an 'update' button? That's not redundancy, that, to me, is common sense. Unless our goal is a minimalistic UI instead of a more functional one.

Contemplating the other possibilities: I think folder creation/editing is basically the same thing. I do agree on deleting, I suppose, though you're ultimately doing the same thing, as the already does: Select folder for deletion, press delete button vs Select folder for deletion, press yes to pop up window (the only difference being you don't get a pop-up menu if the folder is empty - which I personally don't mind but some people might want to be asked for confirmation even if the folder's empty - ideally there'd be a settings option for this). Anyway, it COULD be more convenient if you make a delete button instead of a delete tab/page/section, which then takes you straight to selection list, which then lets you delete it. Alternatively, you have a delete button in the folder editing/updating menu (Could these be combined - the folder icon and apps in it, + delete button, in the same menu, and seperate bits for folder create and activate/deactivate?). Anyway, if you do that, then combined with pop up message for confirm/cancel delete would be both more efficient and more convenient otherwise.

Quote:

When choosing applications to add to a folder, applications that have already been added to the folder are not filtered

Agreed. That would be useful, but I just didn't think of it as part of the UI.

Quote:

Once the app is considered stable enough, the activate/deactivate can be removed entirely (or activated by default and moved to the app menu).

agreed with the parenthetical one. I myself would probably never use the disable option, but it's worth having, I think, for those usrs who want it. Not so sure that would make havin it edit the existing hildon.menu a possibility, without doing more voodoo just to have it save the existing one as the "disable" revert point. Unless you mean it should coy the hildon.menu arrangement to start with, but then still edit it's own folders. *shrug*

Meanwhile, I'm liking the direction that Hrw seems to be taking. The main reason I asked at all was worry because of the possibility of UI changes I would significantly dislike being planned, but it's going well so far.