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
- /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.
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.
2) I think, moving forward, we should use buttons instead of links. Partly this
is because it can be hard to see the gap between the links when there is a
series of them. Buttons are much clearer. For example, the
/alpine-baselayout/interfaces/read page has four links as "Edit Delete ifup
ifdown" which tends to look like one confusing link. That being said, I would
like to get the css to show a list of buttons all in one row, rather than one
row per button.
Also, I intend to change more actions to be forms, so buttons are fitting. The
thinking behind this is that in order to create an interactive console client
for ACF (which I need to do) you need more information. For example, actions
such as /alpine-baselayout/interfaces/delete,
/alpine-baselayout/interfaces/ifup, and /alpine-baselayout/interfaces/ifdown
require input to tell which interface to act on. Right now, the logic for that
input is embedded in the HTML view. There is no way for a console client to tell
what input is needed. So, I intend to change those actions to be forms that
prompt the user for the needed input. For HTML views, the logic can still be
embedded in the link / button. But, a button probably makes more sense.
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 don't understand the problem with the modules, as that is not duplicated
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.
----- Original Message ----
From: Timo Teräs <timo.teras_at_iki.fi>
Sent: Wed, March 2, 2011 8:09:18 AM
Subject: [acf] Web UI Design Principles
I'm planning to:
1. Clean up the Network->Interfaces module
2. Clean up / fix acf-dnsmasq
3. Write an acf to do updates of USB / CF from ISO image
(via HTTP form file upload or HTTP UTL to get)
4. Write a new acf for something I need
And I wanted to get some clean design principles on what we should look
like. I'm currently doing my testing using mhavela's "wik" theme which I
find very nice.
But now I'm a bit puzzled on how certain things should be displayed.
So I'd hope to get us started on "policy how to design acf UI". Below
are the first, most important items we need to focus on.
There's (at least) three different UIs for creating a new thing X in acf
1. Create New Interface. It's a tab of it's own under
Network>Interfaces. The tab is visible, and has the form for creating thing.
2. Create New Cron Job. Is System>Cron, Jobs tab. It lists all the jobs
which exist. But also embeds the full form to create a new job.
3. Create New User. Is in System>Users, Administration tab. You first
need to click the 'Create' button which takes you to new tab (which is
not displayed at al). There you have the form to create new thing.
4. And I believe ACF-tinydns has row based thing where you can click
+/- icons to add or remove entries
We should fix ACF to follow consistent way to do similar things. Which
one would be the preferred choice for "creating a new thing X"?
Additionally, there was some recent changes on changing links to buttons
in certain places. Do we have a guideline set when to use hyperlink, and
when to use a form button?
There's certain elements duplicated in a lot of places that IMHO
makes the interfaces confusing.
Tdtrask already added init.d control-panel to the generic 'status' tab.
And I started removing the control-panel from the expert tab and some
other places. So we probably need 'Save and reload' button next to
'Save' so that user won't need to navigate back and forth to status page
to do the restart.
Also, currently some information in the 'General health' is duplicated
in all over other ACF's. I'm mostly annoyed by the 'Modules' section,
but there's some tidying up in other places too. Do you have any ideas
how to clean up those things?
And re: acf for updating firmware from ISO image. I'd like to probably
make it part of alpine-conf and rename the "System>Local backups" as
something like "Configuration>Commit changes" or similar. And adding the
update thing as "Configuration>Update firmware".
That's it for now. I'd be especially interested to hear on the way we
should do the "add new thing X".
Received on Wed Mar 02 2011 - 06:17:31 GMT