Mail archive

Re: [acf] Web UI Design Principles

From: Ted Trask <>
Date: Wed, 2 Mar 2011 08:01:40 -0800 (PST)

I agree that things should be made consistent. Modifying interfaces and password were not even on my list, but I guess they are now. :) I forgot about /alpine-baselayout/health/modules. Yes, it is redundant and should be removed from one or the other. My inclination is to remove it from health, since it's not related to system health in any way. Actually, health is kind of misleading. The Network tab is redundant to Interfaces status. Modules is redundant to modules status. Not sure what I want to do there. You mention that LBU is a separate package, but it's not. /sbin/lbu is found in alpine-conf package. I would like to keep acf packages corresponding to the packages they support, so acf-alpine-conf goes with alpine-conf. As for the menuing, each controller gets a separate main tab. If you would like to change the alpine-conf/lbu controller to alpine-conf/alpine-conf and add in setup- script type stuff, that's fine. That way your flash stuff could be in the same main menu tab as lbu, but I don't see another main tab as a big deal. Yes. System logging is in need of some TLC. Ted ----- Original Message ---- From: Timo Teräs <> To: Ted Trask <> Cc: Sent: Wed, March 2, 2011 9:40:50 AM Subject: Re: [acf] Web UI Design Principles On 03/02/2011 04:17 PM, Ted Trask wrote: > Nice to have your help Timo. > > 1) Creating a new thing: > If you look a little deeper, you'll find that each action for creating >something > > new stands on its own, it's just not always in the menu. > - /alpine-baselayout/interfaces/create has it's own menu entry > - /alpine-baselayout/cron/createjob does not, but is included into > /alpine-baselayout/cron/listjobs > - /acf-util/password/newuser also doesn't have it's own menu entry, but has a > button in /acf-util/password/status that accesses it > - acf-tinydns doesn't have a create form like the others. The js page you're > referring to actually directly edits the config file in js. Underneath, the > /tinydns/tinydns/edit action is equivalent to /tinydns/tinydns/editfile except > for the fancy js view. Also note that neither of these actions have menu >options > > because you need to select which file to edit. Ok. Yes. I was just mostly talking about how user sees the task. Even if from coding point of view they are mostly the same, from user point of view they are all completely different. > So, in general I would say that the preferred method is the way that > /alpine-baselayout/cron/listjobs does it. /alpine-baselayout/interfaces and > /acf-util/password are both very old. You'll find that the newer ACFs generally > > use the 'include the create form after the list' method. Ok. I'll try to follow that then. Though, I'm not sure if I like the idea that one has to navigate to end of page to create new things (or skip the possibly long form to see the existing things). Perhaps we should have some javascript to hide the "create new thing" and expand it someway? Or any other ideas for this? > 2) I think, moving forward, we should use buttons instead of links. Ok. Makes sense. I suppose this gives more possibilities for skins too. > 3) I don't like removing the startstop action from the config / expert tabs. I > also don't like the idea of a 'save and restart' button. Save and Restart are > two separate actions, they should be separate steps. Further, I like keeping >the > > buttons on the expert tab so extra navigation is not necessary. In general, the > > duplication of information and forms is done for convenience just like that. I understand concern with 'save and restart'. But as an user, I'm get annoyed the more clicks I need to do for changing something. We already have navigation to proper place, Save, Restart and finally doing LBU commit. Combining 'Save & Restart' is IMHO a good candidate for simplification. This would be in addition to the 'Save' button. Single 'Save & Restart' instead of full startstop action (taking the additional header space) is too space consuming IMHO. If you are still against the combo button, how about then modify 'Save' click to return back to 'Status' page? The less we have controls and items per single page, the better our UI is. > I don't understand the problem with the modules, as that is not duplicated > anywhere else. There's: System>General Health, Modules System>Modules, Status which are about identical. I think certain bit of information should be in only one place. The only exception being overview pages that collects *overview* information form different places to single page. I'm thinking that maybe we could merge System>Modules System>Init to System>Bootup and include there only the configuration tabs. Since Health contains the modules info. The less we have menu items per the better our UI is. Obviously having less does not mean that we sacrifice on functionality. But duplicating info to get more pages is just not good thing to do. > 4) I'm open to changing the alpine-conf menuing, but I don't understand your > suggestion. acf-alpine-conf, in theory, is an ACF for all features of the > alpine-conf package. As of now, only lbu is supported, whereas the package also > > includes a bunch of setup- scripts. So, it makes sense to add setup- script >type > > functionality. My first thought would be to leave the current "System > Local > backups" menu alone and add a separate "System > ???" menu option for your new > stuff. The acf-alpine-baselayout package already does something like this, > actually containing multiple controllers with their own menu options. Oh. Ok. But LBU is it's separate package. Maybe we should delete alpine-conf for now, and segregate LBU + Flash update to it's own acf-flash or something similar. And as additional thing, we need a way to have "System Logging" detect if we are using sysklogd; it's assuming busybox now. - Timo

Received on Wed Mar 02 2011 - 08:01:40 GMT