Re: Use of MidCOM toolbars

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

Hi,

- --Henri Bergius wrote on 2006-02-14 09:37:
> Please comment.

Before we are going about the technical implemetnation on this, I recommend that
we focus a bit on the usability point of it first:

> I would propose the toolbars to be used in the following fashion:
> 
> * `top`: actions user can take, including "Create article", "Report
> as spam"
> 
> * `bottom`: different views of the same object or listing, including
> "Edit", "Delete", "Revisions"

Generally I agree for this distinction.


> * `aegir_menu`: Global actions like "Help" and "Logout" (help should
> be contextual help using the midcom.admin.help component)

I recommend naming this simply "admin", as it is not bound to aegir2 but to
general administrative tasks; system administrators could have access to more
advanced options like cron jobs etc. as well here. Also, logout should not be in
that toolbar, but replace the login form on-site by default. IMHO at least.


What I'm wondering now is how the Site style authoer can render these toolbars.
The old toolbar set was always interconnected, they were displayed immediately
adjecant to each other.

This is not always viable in a live site style I guess.

Then, what's "aegir-location" for?

Also I'd recommend renaming the "top" and "bottom" toolbar to something more
meaningful, perhaps node/object.


One (big) conceptual problem is this:

> First you need to get it by:
> 
>      $toolbars = &midcom_helper_toolbars::get_instance();

That is the very best way to break your neck with dynamic_loaded stuff. Toolbars
must be MidCOM request- not HTTP request-specific, otherwise you'll end up with
tons of unneccessary icons in the toolbars. (And if-checking for being in
request 0 everywhere you use toolbars makes no sense as it is error prone.)

Instead, the toolbars have to go into the request context (custom data area),
much like the NAP breadcrumb line extensions do.

That way, dl'ed stuff can also have its toolbars as much as they (or the style
authors) deem neccessary.


Essentially I think we should work out some illustrated style/UI guide that we
adapt components to step-by-step. This should focus not on technical issues but
on presentation and functionality. It is imperative, that various constellations
are taken into account there, not just simple I-display-a-single-article cases.
DL, stuff like OpenPSA or Aegir2 or complex homepage portals must be considered
there as well as the basic, simple cases.

- From there we can then dive a) into the technical details and b) into various
ways of displaying the toolbar content.


As for a few technical notes:

1. Already at tigris is the support for POST forms

2. We also need submenus, preferrably in some kind of dropdown style.

3. There should be a way where the toolbars added to the system just are
represented in their own dropdowns. (Well, essentially a real menu system would
be great.)

4. The toolbars need some more default options, so that you don't have to
specify every single option each time (like ENABLED=true or HELPTEXT=null)

5. When this all stabilizes, the toolbars will go into the request classes for
easy access.


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

iD8DBQFD8Z8iJPh4Kn6d5FYRAtcrAKDnh4FaXdl9zQGhtczGBHPBc5IjjgCgsrKC
VKa0aaK3zKJu5vL7owdu4EI=
=rAUQ
-----END PGP SIGNATURE-----