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.
----- Original Message ----
From: Timo Teräs <timo.teras_at_iki.fi>
To: Ted Trask <ttrask01_at_yahoo.com>
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
> 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
> - /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
> 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).
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
> 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.
System>General Health, Modules
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
and include there only the configuration tabs. Since Health contains the
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
> 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.
Received on Wed Mar 02 2011 - 08:01:40 GMT