UI proposals (was: Use of MidCOM toolbars)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

- --Henri Bergius wrote on 2006-02-16 16:15:
>> See my other mails, this about matches the distinction I have proposed,
>> with the "top" toolbar holding operations that apply generally to the
>> current node, while the "bottom" toolbar contains operations that apply to
>> the current "view".
> 
> Some actions in "top" don't apply to node. For example, "Create SMS
> message" in o.o.directmarketing creates new message under a campaign which
> is theoretically a leaf.

Point taken, so I relax my requirement a bit: "top" takes operations not
directly affecting the current object (which is managed by "bottom").

As I said in our private IRC conversation: The distinction is a bit fluid, as
there are operations (like that sms thingy) that could very well fit into both
toolbars without getting into problems argumenting for your chosen solution.

There is one more thing that should be thought about: Actually we have *three*
levels of navigation (for a first sum-up, my worries are outlined below):


1) NAP Leaves: I currently use them for things like "My Entries" or "Archive" as
well as for direct object links, depending on the component. Only simple
components like taviewer (soon to be called net.nehmer.static) still map their
actual content objects into it. Many components now only provide Meta-Leaves
(both for speed and simplicity).

2) "Top" toolbar: Containing generic operations not directly affecting the
currently "active" object. (Which is usually related to Node operation.)

3) "Bottom" toolbar: The logical opposite of top.

And, in parallel, there is the new enhanced NAP Breadcrumb system, which allows
components to easily construct BC lines like "Home > taviewer > Article > Edit".
They're now multi-level and not bound to leaves anymore (though the leaf still
gets added automatically). Thus, you can provide an even greater detail in
Navigation - if you need that.


One thing that is still a bit undefined to me: How should we treat
administrative operations which are *not* part of the actual component, like
Topic management? Traditionally they have been part of what's now known as the
"top" toolbar. Without dropdowns I fear that could lead to "overflowing" the
toolbar depending on how exactly we do navigation there.

>> Also, I wonder what happens if topic management specific operations start
>> to be added to the "top" toolbar.
>
> I think there could be a "top" item "Manage folder" that would lead you to
> the topic management view, where this stuff would obviously be in
> "bottom".

We could of course just add this single "folder management" option to the
toolbar, and doing everything from there (essentially not allowing further
modification of "top").

What is important here (and for me mostly to worry about) is a way for the
administrative system to plug handlers dynamically into the currently running
request - without having to change that in every component.


Then, we have the problem of various request contexts: I'm still not sure how to
handle this. Normally, each context should have its toolbars available. But that
 could clog up the whole UI with many toolbars. But you do want parts of them.
For example, take this case of a simple homepage:

+------------------------------------
| TAviewer driven intro text
|
| [EDIT] [DELETE] [CREATE]
|------------------------------------
| Newsticker DL
|
| Article 1
| [EDIT] [DELETE]
|
| Article 2
| [EDIT] [DELETE]
|
| Article 3
| [EDIT] [DELETE]
|
| [CREATE]
+------------------------------------

As you can see, there are (theoretically) many toolbars in a full on-site admin
setting, especially if we want to make the administrative options quickly and
transparently available.

This especially includes IMHO that the placement of the carious toolbars is
highly-dynamic, or perhaps better highly-component-specific. To make this
feasible (especially for the newsticker scenario) a toolbar which only uses
icons could be very useful:

Article 1 [edit-icon] [delete-icon]

Then, for DL parts of the topic toolbar should be hidden, it doesn't make much
sense to have folder management etc. there (in contrast to create).

So maybe now you see why I'm a bit confused by the "simpler"
two-toolbar-approach, which doesn't really allow such a sophisticated UI.

Take a look at the following screenshot how this could look:

http://www.nehmer.net/~torben/wegbui.png

It is taken from Webguid (www.plainblack.com), which is a quite nice Perl-based CMS.

Of course, building like this needs a more flexible toolbar system where
components have more control over it.


Live long and Prosper!
Torben Nehmer

- --
Torben Nehmer, Guenzburg, Bavaria, Germany
http://www.nathan-syntronics.de, mailto:[email protected]
PGP Public Key: https://www.link-m.de/pgp/t.nehmer.asc
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFD9KKhJPh4Kn6d5FYRAlVfAJ42M7i5DMwnn/NC7ENHYvLBOjch0QCgpis9
+J6FJI8hHv7RnbGgrniR6H0=
=tI9X
-----END PGP SIGNATURE-----