User Interface & ergonomy [Archive] - Mambo

YTW

October 6th, 2004, 07:17

Now that we have a stable 4.5.1 release, I wish that the administration ergonomy/user interface will be in-depth reviewed for the next 4.5.2 release

We had major functionalities added ion 4.5.1, so it's rather normal that the ergonomy of the product has left margin for improvements. Still there are some obvious quick fix that could be done:

Some examples:

- Template manager has no icon in the Control Panel
- Imagine you are in the following section: Site/Templates manager/Site templates, and that you want to install a new template
You have to go again in the same menu to find the install link. Can't we add a shortcut link to the Install in site templates page ?¡And vice versa, once you are in the Install template page, have a link to the Site Templates page

- Names should also be reviewed, there are several Install in the same menu. Might be worthy to say what we install
- The Module Position in that template menu seems a bit out of place....
- The alternative of the drop down menu is not 100% operative (turn off javascript and see waht you get)......I would personally use better some split menus than a drop down menu, having main items in an horizontal bar, and all remaining subitems nested in a vertical left column
- The overall navigation could be optimised to target a 3 levels of items in the menu admin (Content sections items go up to Level 4)
- etc...

These are very small issues, but the sum of very small issues can finally make a product not so intuitive. And for me, one of the major argument to use Mambo is its usability & ease of use.

Review a product ergonomy is a complex task that requires some objetive/new view. Experiences from other CMS could be interesting track to start with.

My 2 cents

PhilTaylor (aka PrazGod)

October 6th, 2004, 17:28

if you wish to submit these issues - one at a time - to the bug tracker we will work through them when we have time :-)

stingrey

October 6th, 2004, 18:36

Firstly we appreciate all feedback, so keep it coming.

- Imagine you are in the following section: Site/Templates manager/Site templates, and that you want to install a new template
You have to go again in the same menu to find the install link. Can't we add a shortcut link to the Install in site templates page ?¡And vice versa, once you are in the Install template page, have a link to the Site Templates page
I'm thinking of maybe having a quick links bar at the bottom of admin pages like templates, that link to other areas related to that page.
E.g.
Content Item Manager would have links to Section and Category Manager
E.g.
Module Manager would have links to install

The overall navigation could be optimised to target a 3 levels of items in the menu admin (Content sections items go up to Level 4)We've had considerable internal debate over how to layout the Content Menu in admin and I agree that its not the best solution, but we havent been able to find somethign that works better.

tonyskyday

October 6th, 2004, 18:41

How much of this is controlable with admin template design, and how much is the result of fundamental methodoligies of the Mambo admin?

idigital

October 6th, 2004, 18:51

Well, you can do a lot with the existing backend template system, and can do a lot more with a bit of hacking ;)

I suspect that eventually it will all be configurable and customisable to a point that will satisfy even the most advanced user.

ATM, you could just create a backend template that has a menu that links to custom "core" components, then you could customise the look and features of the backend as much as you like.

Ah, wish I had the time. ;-)

Cheers,

Damian

p.s. Backenders will explore this further, once I've finished off this major development in about a month.

YTW

October 6th, 2004, 23:50

The fact that is can be customized via the back-end templating system is great, but you have to think that 95% of the mambo user will not have the time nor the skills to adapt the back-end admin. The admin panel is a strategic element of the Mambo CMS that would need to be designed and implemented by the core dev team (my view)

-----------------------------------------

Phil I don't think the examples provided in the first post can be considered as bugs. Ergonomy/User interface requires an global analysis and a strategic thinking. Analyze first and once global tracks of improvements clearly appear, then corrective actions could be taken (if any)

-----------------------------------------

Suggested methodology for an ergonomy/usability study:

Group1 - Existing solutions oriented - Bottom Up approach

What is needed to start with, is a competitive review of how mambo behaves in comparison to [Name here 5 competitors]. The most important processes to review are to defined, but should encompass:

-The installation process
-The content creation process: Write the content, choose its type (eg in Mambo, content item or static item, blog, component items....), assign the content to one or several menus...
-The customization process of core scripts like modules/component/templates/mambots in the Mambo case
- The Scheduling process
- The Archiving process
- The Administration processes (back-ups, systems info, statistic collection & display, seo, trash...)

The objective would not be so much a functionnalities review (when chosing your competitors you asume that functionalities are more or less equivalent) , but much more how intuitive, simple and straight forward are the current processes in competitors' CMS

Group2 - User oriented - Top Down approach
In parallel another small group of people could try to define the "ideal" processes, without entering in the details of the solutions as group 1. This groups would have a great conceptual freedom to also study disruptive solutions, like total freedom to rethink from scratch the Mambo admin panel. Surveys posted in the community forum could help in knowing what the users want, and rank their needs by priorities

This way 2 different approaches would then be compared (Bottom Up) & (Top Down), and normally, matching the results of the 2 work group you get the best trade off of what would be conceptually the best and what would be practically the most feasible

BTW I don't say that the competitors are doing much better, but i am 100% sure that their will be great value creation for the Mambo community in studying doing such a survey.

-----------------------------------------

Bottom Line: In the long range, HOW things are done is as important as WHAT can be done. There is no time pressure. Just a need maybe to set-up/re-activate a permanent Usability/Ergonomy activity whithin the dev team.

No offense at all, 4.5.1 is an excellent product, and the dev team is doing a fantastic job. Just thinking in making Mambo the nº1 Free CMS product

stingrey

October 7th, 2004, 00:05

I think a usability study would be very useful, maybe you could coordinate this inline with the new 3rd Party Standards Team being setup by grutkowski:
http://forum.mamboserver.com/showthread.php?t=18188

What I mean is that I believe this is something probably best handled by someone not on the dev team so we can get a fresh perspective on the matter.
After a while looking at the code you've written, its harder to give an objective evaluation of it.

Were always looking for ways to make mambo better, os if a competitor does something better, were happy enough to see if we can utilise the idea within mambo.

YTW

October 7th, 2004, 02:38

I think a usability study would be very useful, maybe you could coordinate this inline with the new 3rd Party Standards Team being setup by grutkowski:
http://forum.mamboserver.com/showthread.php?t=18188

Yes I have seen this iniciative. Important one too, tough I think that the issue we are discussing now is a bit different.

What I mean is that I believe this is something probably best handled by someone not on the dev team so we can get a fresh perspective on the matter.

You are right, it's a kind of Audit, and I agree it should ideally be externally done. I know quite well how similar projects works and in many cases they fail in finally implementing the result of the study if:

- The audit team is not officially mandated by the decision makers (in that case the dev team)
- The inicial objectives & scopes are not defined and validated by the decision makers (in that case the dev team)
- The way the results of the study will be presented, assessed and accepted/rejected in not defined before end (in that case the dev team)

The goal is to have actions performed after the audit, and that's often where the things goes wrong...Who's that external guy recommending stuff. I does not know a s.... of our product/project/company ... stupid consultants...and so on

That's why, very often, finally people prefer to have this kind of study done internally. And that's also the approach i would chose. It generally results in more results than the external audit approach

stingrey

October 7th, 2004, 06:44

YTW I've emailled you via your contact form on your site and want to discuss this further directly, if you dont get an email can you contact me via my sites contact form.

Cheers
Rey

Jinx

October 8th, 2004, 10:06

I've read this thread with great interest. I agree with the idea that usability, accessibility, ergonomics become more important with the expansion of Mambo. One can bundel all these topics under the flag of user-centered interaction design.

Interaction design is mostly involed around site workflows, processes and user centered design. We need to make a clear distinction between backend and frontend here.
The frontend template defines the site design, with mambo being a page based CMS the focus in these templates lies on site structure, user centered content, ... The template designer/information architect is responsability for the frontends interaction design. Mambo's main responsibility lies in making sure a site designer doesn't feels blocked in his design process by the frontend system. I believe mambo is evolving in the right direction here.

The backend template serves a different goal then the frontend. The focus here lies on workflow and content processes. Mambo's growth also requires a more flexible backend administration section. Not all users will use Mambo the same way. One could offcourse try to implement all user centered processes in one backend template. This will however never benefit the user, dfferent users will require different things at different times. I believe that one should beable to create different backend templates for different user processes, workflows. A users who want's to use Mambo as a blogging system has completely different goals then a user who want to use it as a file/music repository.

I believe that the chalenges for future versions lie in interaction design.

Cheers,

YTW

October 12th, 2004, 10:34

100% agree with Mr Jinx. The front end is very powerfull in 4.5.1 and will be given extended possibilities with the introduction of the pattern templates in 4.5.2. This post should be understood as primarly referring to the back-end admin

How to minimize the learning curve impact and maximize the functionalities/possible applications, that's the Challenge mambo has now to answer

Having several admin templates for different applications (Corporate Web sites, Bloggs, Portal/Community web sites,etc...) is a nice idea. But I am affraid that the energy that empowers Mambo has to be unique (understand the workflow & processes). And here is the issue. Starting from the target market positioning Mambo want to have, we have to check if the current admin processes correctly serves the goals or not. In any cases, the admin panel has to be made more user friendly, intuitive and simple. The learning curve impact should be minimized.

Ask any experienced 4.5.0x users how much time they have needed to reasonably master 4.5.1 ?¿
IMO, Mambo is a fantastic tool for experienced amateurs and professionals. Let mambo in hands of a real CMS newbie and you can make sure that nothing will happen. If the goal is to expend Mambo to the Mass, then we need to reinforce the User Experience/Ergonomy/Usability activities.

Bottom line:
:arrow: Mambo is Plug & Play for expert members and people sensibilized with CMS matters. Even so, the first approach can be rather traumatic (people migrating from another CMS could give a usefull input here). For the rest of the world, it's far too complex for any uses, and any improvements made in that area is now as important as a technology move or the introduction of a new feature.
We have to switch from an expension/growth mind (WHAT features do we need to include) to a consolidation/maturity spirit (HOW the things are done). Needless to say that we have to maintain at the same time the excellence in the WHAT, but i personally have no reasons to worry on these aspects.

My 20 cents

Jick

October 12th, 2004, 12:19

After reading these posts I was thinking about the control panel as a sort of windows desktop.

I think the way it is now is to static to serve as the 'main base' off the admin.

How about having a component to manage the cpanel, some admins would like to have shortcut one at the 'desktop' and an other would rather like to have shortcut two up there.

If admins could set up there own personal cpanel the way the like to use it best it would be a step forward in easy handling of the admin section I think.

Also a link to the cpanel in the toolbar like 'cancel' would be very handy to reach the admin 'main base' from various locations.

Just spinning my brain ;-)

Jick

mambosolutions

November 18th, 2004, 16:00

Hallelujia and Amen!

I can't agree any more and I have been saying this for a few months now...even when 4.5.1 was in beta... the whole discussion about 'static content items...the way they were made in 4.5 versus 4.5.1

IMO, it is MORE important to step back away from the code, from the new features for a moment - that moment may be a week, a month, as long as it takes - to take what we have and refine it, make the user expereince as friendly and 'dumb it down' as much as possible to make it easy for the masses.

We already have a rocketship, but how many people can fly a rocket? Let's aim to have the power of the rocket, with the intuiveness of riding a bike.

Bottom line:
:arrow: Mambo is Plug & Play for expert members and people sensibilized with CMS matters. Even so, the first approach can be rather traumatic (people migrating from another CMS could give a usefull input here). For the rest of the world, it's far too complex for any uses, and any improvements made in that area is now as important as a technology move or the introduction of a new feature.

MasterChief

November 18th, 2004, 16:11

For those with CVS access, there are some musings in the current dev version around this topic. Not everything works but have a look a the conceptual ideas in:

Site->Folder Manager (possible replacement for sections and categories)
Site->User Manager (hey, did someone say you can now edit the groups)

Feedback would be appreciated.

mambosolutions

November 18th, 2004, 16:19

how can i get CVS access?

MasterChief

November 18th, 2004, 16:31

http://mamboserver.com/cat/Download_Mambo/

I had to search for it myself :)

YTW

November 19th, 2004, 04:57

I'll play with CVS release this week-end and let you know something about it next week

UPDATE:

In C:\Documents and Settings\Pop.PROPIETA-4CI361\Mis documentos\My Business Opportunities\00. mambo official\4.5.1: C:\Archivos de programa\TortoiseCVS\cvs.exe -q checkout -P MamboOS
CVSROOT=:pserver:anonymous@mamboforge.net:/cvsroot/mambo

cvs checkout: Empty password used - try 'cvs login' with a real password

cvs server: cannot find module `MamboOS' - ignored
cvs [checkout aborted]: cannot expand modules

Error, CVS operation failed

Are you sure of the CVS parameters ?¿

UPDATE 2: The tortoise parameters in the URL provided are wrong, find enclosed the ones that have worked for me

------------------------------------------------------------

Just downloaded the CVS and seen
19-Nov-2004 Andrew Eddie
+ Added basic multisite capability
:-)

MasterChief

November 19th, 2004, 14:25

Thank YTW. I've uploaded your replacement graphic.

Jinx

November 19th, 2004, 16:02

We already have a rocketship, but how many people can fly a rocket? Let's aim to have the power of the rocket, with the intuiveness of riding a bike.

Spoken like a real poet, i couldn't have said it better !

mambosolutions

November 19th, 2004, 16:55

ok time for me to confess, i am a CVS illiterate...what do i need to get rolling? I remember once I tried a program called Tortoise...i think...

what do you guys use?

*edit* nevermind..i got tortoise now and am checking out the CVS

mambosolutions

November 19th, 2004, 18:15

wow! 5 minutes later, I have CVS running inside MSAS...easy peasy.

quick look around CVS..I see the folder manager...liking this idea..would like to see some graphics to add to the usability...how about some folder graphics instead of the indents on the left column ( i know, i know graphics always come last) maybe even the idea of user definable colors for each folder graphics - to assisit in visually categorizing things..

Next.. in the View Content area of each content of the folders...

on top there is Edit | Folders | Access | Properties

how about another one called 'Link it' and dropdown of all current menus in the site with ability to add the link from this same pane?

IMO this is one of the sorely missing things in the transition from 4.5 to 4.5.1--the abilty to create a content and link it to a menu from the same page, without having to clcik back in after its saved...

Jinx

November 19th, 2004, 19:11

On windows i use tortoise, work like a charm

stingrey

November 20th, 2004, 05:16

quick look around CVS..I see the folder manager...liking this idea..would like to see some graphics to add to the usability...how about some folder graphics instead of the indents on the left column ( i know, i know graphics always come last) maybe even the idea of user definable colors for each folder graphics - to assisit in visually categorizing things..
As you've alluded to graphics is something for later consideration when the code and concept has been cemented.
Also an important consideration with all graphical 'nicities' is what will this cost in terms of load speed.
Important in our work is to try overcome the significant loading times in 4.5.1 So an important consideration is always whether the tradeoff between graphical UI's is worth the loss in speed and whether they (graphical improvements) really provide more than a cosmetic improvement.

Next.. in the View Content area of each content of the folders...

on top there is Edit | Folders | Access | Properties

how about another one called 'Link it' and dropdown of all current menus in the site with ability to add the link from this same pane?

IMO this is one of the sorely missing things in the transition from 4.5 to 4.5.1--the abilty to create a content and link it to a menu from the same page, without having to clcik back in after its saved...
If you play with the CVS, you will see that the the 'Link to Menu' feature has been corrected so you no longer have to save your entry once before you have access to this feature. It will also now save the edits you make before creating a new menu. Also minor improvements like being able to link to the menu item or menu in question have been added.
However this may well be a moot point as we are exploring how the menu creation system can be overhauled especially in light of the improvements to content structuring as made possible by the changes to the ACL

mambosolutions

November 20th, 2004, 07:06

I would argue that if graphics help make the administration more user friendly, the benefit of using more graphics outweighs the slight increase in load time. these graphics I suggest would only be tiny, like 3k and since we are talking about the load time of the 'back end' not the front end, i I would argue that load time is really not a factor.

As you've alluded to graphics is something for later consideration when the code and concept has been cemented.
Also an important consideration with all graphical 'nicities' is what will this cost in terms of load speed.
Important in our work is to try overcome the significant loading times in 4.5.1 So an important consideration is always whether the tradeoff between graphical UI's is worth the loss in speed and whether they (graphical improvements) really provide more than a cosmetic improvement.

i didn't catch that...good on ya rey - i know you were the one who implemented the link to menu functionality in 4.5.1 definatle a step in the right direction...although I look forward to this overhaul of the menu creation system.

After doing a bit of thinking last night about the UI, i came up with these observations:

-the UI in 4.5.1a is disjointed. There is plenty of functionality, but lots is buried in tabs and submenus.

there are 3 different navigational elements in the UI. i would say that there should be only one or two to simplify things for the user.

in the moment, we have

1)top horizontal menu, some places it has even 4 sublevels, which right there is a red flag for usability.

2)we have icons for certain areas (static content manager etc) but not icons for all areas(templates manager as example)

3) we have tabbed navigation for parameters

maybe it would be an good idea to rethink this - the first thing that pops in my mind is continuity. Choose one UI element (tabs, icons, derop menu) and use it throughout the admin panel. CPanel comes to mind although as a rough idea....

If you play with the CVS, you will see that the the 'Link to Menu' feature has been corrected so you no longer have to save your entry once before you have access to this feature. It will also now save the edits you make before creating a new menu. Also minor improvements like being able to link to the menu item or menu in question have been added.
However this may well be a moot point as we are exploring how the menu creation system can be overhauled especially in light of the improvements to content structuring as made possible by the ch
anges to the ACL

Jinx

November 20th, 2004, 07:41

As you've alluded to graphics is something for later consideration when the code and concept has been cemented.
Also an important consideration with all graphical 'nicities' is what will this cost in terms of load speed.
Important in our work is to try overcome the significant loading times in 4.5.1 So an important consideration is always whether the tradeoff between graphical UI's is worth the loss in speed and whether they (graphical improvements) really provide more than a cosmetic improvement.

Stingrey,

This isn't a consideration u need to make, leave this decision to the user/template designer/developper. Like Theodicus (http://arlen.f2o.org/archives/2004/10/19/content-content-whos-got-the-content/)said : 'alas, Mambo (and every other CMS I’ve tried) is doing more, and that’s what causes designers to tear out huge chunks of hair.'

The backend icons are nothing more than layout, they have no semantic meaning, so they shouldn't be hardcoded in the html. By using semantic correct coding (http://forum.mamboserver.com/showthread.php?t=19422) u can move the icons to your css. This will not only improve load times, i will make i quite easy to change/remove the icons.

Speaking about load times, a few images will not have such a hard impact on load times. Loosing the backend tables, however will !

stingrey

November 20th, 2004, 08:14

I would argue that if graphics help make the administration more user friendly, the benefit of using more graphics outweighs the slight increase in load time. these graphics I suggest would only be tiny, like 3k and since we are talking about the load time of the 'back end' not the front end, i I would argue that load time is really not a factor.
True, I'm only making the point that all things need do be considered. I have actually supported the use of more graphical heavy layouts when the team has discussed the backend layout - but like everything all things must be in balance.

As to backend load times not being a factor, I fear a portion of users on dialup would probably disagree. We have noted these comments and we do note that 4.5.1 loads a little slower than 4.5.0 at times.

=========================================

This isn't a consideration u need to make, leave this decision to the user/template designer/developper. Like Theodicus said : 'alas, Mambo (and every other CMS I’ve tried) is doing more, and that’s what causes designers to tear out huge chunks of hair.'

The backend icons are nothing more than layout, they have no semantic meaning, so they shouldn't be hardcoded in the html. By using semantic correct coding u can move the icons to your css.True to certain extent - I would say more for the frontend especially.

But as John points out, a graphical backend is important from the whole user interface point of view.
And all although it is just layout. We are talking about the 'default' mambo backend layout that probably 90% of people will be using. Even with Backend templating I would say most will stick with the default layout. So we do need to consider semantic layout issues.
I'd say part of mambo's success has been its backend layout compared to other CMS's.
When the 5.0 proof of concept came out, the biggest response was a negative one to the removal of the graphical buttons. We've trialled a cut down JSCook menu with no images, and it just doesnt work.
So layout it important to a degree in that it enchances the UI experience.

However, with the use of pT this can be controlled by designers, but we still need to worry about the default layout

stingrey

November 20th, 2004, 08:16

This will not only improve load times, i will make i quite easy to change/remove the icons.
As a side note, it is actually possible to replace the images/icons for the buttons in 4.5.1, it merely involves placing an image in the admin templates /images/ directory with the same name as the image to be replace.

mambosolutions

November 20th, 2004, 08:40

i wasnt alluding that anything need to be hardcoded, in fact I have been one of the people in this community that first brought up the notion that we need to get away from hardcoded presenataional markup in the core over a year ago... i agree with the idea that images and other things can be defined in CSS..the discussion here is not the question of the technical means to achive that - but thequestion of how to make the Mambo (admin) user expereince better

Now that there are admin templates, i would like to see something like Macromedia does with Fash and Dreamweaver, and Allaire did with Homesite-->

and that is have a couple different admin templates that are chooseable from the admin panel.
Imagine when you first install mambo, and at the end of the setup, it ask you to choose which type of admin layout you wish to have: Expert / Easy or Coder/ Editor etc... then of course you could switch later.

just a thought

great discussion by the way

Stingrey,

This isn't a consideration u need to make, leave this decision to the user/template designer/developper. Like Theodicus (http://arlen.f2o.org/archives/2004/10/19/content-content-whos-got-the-content/)said : 'alas, Mambo (and every other CMS I’ve tried) is doing more, and that’s what causes designers to tear out huge chunks of hair.'

The backend icons are nothing more than layout, they have no semantic meaning, so they shouldn't be hardcoded in the html. By using semantic correct coding (http://forum.mamboserver.com/showthread.php?t=19422) u can move the icons to your css. This will not only improve load times, i will make i quite easy to change/remove the icons.

Speaking about load times, a few images will not have such a hard impact on load times. Loosing the backend tables, however will !

YTW

November 20th, 2004, 10:07

Here's a proposal of how things could be organized for the user management section in 4.5.2 or any other release if it's proven to have some interest

User management
--> 1. List
1.1 View: Comprehensive list of the registered user of the site, Id, user name, role, email, group, with latest access and an edit link to allow modifications of the listed accounts
1.2 Contact--> We could maybe connect to the Mass mail function that I have seen active again in the component section
--> 2. Add
2.1 User addition: Allow to manually add one account to the db
2.2 User bulk addition:Would be nice to have a feature for bulk imports via xml file
2.3 Group management:
2.3.1 Create groups
2.3.2 Assign users to groups

--> 3. Configure
3.1 Settings
3.1.1 user registration settings: No register (only admin via back end can create accounts), Automating register via front end, Moderated register via front end (upon admin approval)
3.1.2 User email settings: Allow the customization of the different email messages (New account created, Pending approval, Lost pasword recovery,...)
3.1.3 Allow picture support for user Yes/No + different parameters if allowed (default image url, max size in pixel & kB
3.1.4 Who’s online parameters: Who’s online time set-up (after X minutes a user is considered online) + max online users displayed in Who's online the module
3.2 Roles
3.2.1 View List of pre-defined & locked roles (non registered (guest) registered & admin)
3.2.2 Add: form to create as many new roles as wanted. eg: Example: "moderator", "editor"...
3.2 Permissions
List of functions + Roles + Check box You simply activate/disable any function for any role. "A la carte"
Miscellaneous comments:
Locked roles (non registered & registered & admin) should have permissions settings that are shown by default at first load of the page (list of pre-activated check boxes for each role). Then the user could change any of the permission, according to its needs.
It is also worthy to allow a go back to default settings for locked roles, if they have been deeply changed and the user suddenly realized that default settings were best.
A copy permission to create a new role from an existing profile could be a nice feature too

I think this draft proposal is a comprehensive, intuitive, process-based User Management System. It's highly inspired from another existing CMS solution.

Let the discussion starts now, we have a written proposal that allows the debate to start

Jinx

November 20th, 2004, 15:59

...i agree with the idea that images and other things can be defined in CSS..

If u want to create semantic correct markup and provide correct seperaration between content and layout, this would be way to go.

and that is have a couple different admin templates that are chooseable from the admin panel.
Imagine when you first install mambo, and at the end of the setup, it ask you to choose which type of admin layout you wish to have: Expert / Easy or Coder/ Editor etc... then of course you could switch later.

Earlier in this thread (http://forum.mamboserver.com/showpost.php?p=95087&postcount=10) i already wrote about this :

This will however never benefit the user, dfferent users will require different things at different times. I believe that one should beable to create different backend templates for different user processes, workflows. A users who want's to use Mambo as a blogging system has completely different goals then a user who want to use it as a file/music repository.

the discussion here is not the question of the technical means to achive that - but thequestion of how to make the Mambo (admin) user expereince better

Oke, let's offer a few ideas about how we can improve the user experience. We seem to agree in this thread that one way would be showing a different menu systems based on a user needs/type. Also the loading speed of the backend seems to be an issue.

Bearing in mind my previous post (http://forum.mamboserver.com/showpost.php?p=114173&postcount=25), i would propose the following. First of all I believe that we should get rid of the JSCook menu, for the following reasons.

It isn't semantically correct
It is very unflexible
It uses obstructive javascript

The mambo core should only concern itself with outputting semantic correct code from which a menu can be styled. The best solution to use in xhtml these days are unordered lists. Unordered list can be styled in a variaity of ways using css. Adding unobstrusive javascript to the mix allows u to create a full-featured dropdown menu system. (http://exp.jinx.be). U could use Flash to read in the unordered list an tranform it in a Flash menu system or, if u want to use FireFox capabilities, add a little XUL to the mix and u will have a very fast cross-platform menu.

What i'm saying is don't think for the user, let the backend menu styling depend on it's context. Offcoure u could create a default template that use a predefined approach, u could even create 2 templates one for low speed and one for high speed connections, but always remember a template is nothing more than adding layout and behavior to markup.

Jinx

November 20th, 2004, 16:00

Here's a proposal of how things could be organized for the user management section in 4.5.2 or any other release if it's proven to have some interest

Maybe it's better to move this discussion to a new thread ?

mambosolutions

November 20th, 2004, 16:17

i love that menu example you posted is that from http://www.youngpup.net/2001/ypslideoutmenus

?

i played with this for a long time..very smooth

I agree with what you are saying about seperation of code and presentation.

a majority of the folks will be using the default admin template, so its key that we discuss how to make that as simple, intuitive and user friendly as possible.

mambosolutions

November 20th, 2004, 16:18

Maybe it's better to move this discussion to a new thread ?

agree...

YTW

November 21st, 2004, 02:17

mambosolutions

November 21st, 2004, 02:31

IMHO, the real issues are not really discussed in that post:

How much does the admin panel answer the needs of the user ¿? (understand functionalities)
Waht should be the main blocks in the admin panel ?¡ (understand process definition)
How intuitive is the current admin panel ?¡ (understand overall navigation system)
How can we leverage the learning curve impact ¿? (both for newbies & people coming from another CMS)

I would say the real issues are being discussed in this post

..the discussion here is not the question of the technical means to achive that - but thequestion of how to make the Mambo (admin) user expereince better

- and thats what I believe we need to focus on

maybe we need to make each our own idea of what would be an ideal default admin template for mambo, post our screenshots, and discuss? I am a visual person, i can communicate better with graphics

YTW

November 21st, 2004, 02:42

Yes John, but i would suggest that we focus on something the dev team has asked some feedbacks:

4.5.2 CVS user management --> there is a new post for that
4.5.2 CVS folder directory --> there will be a new post for that today

Alll ideas/graphic/sugestion/experience from other CMS/whatever are welcomed

Jinx

November 21st, 2004, 09:15

i love that menu example you posted is that from http://www.youngpup.net/2001/ypslideoutmenus

No the concept is based on youngpup, sukerfish dropdowns (http://www.alistapart.com/articles/dropdowns), and pure css menus (http://www.meyerweb.com/eric/css/edge/menus/demo.html). The code however is completely different than youngpup's implementation. The menu system i create is an "Elastic Hybrid CSS-Javascript" menu.

Elastic : meaning the menu adapts to the browsers font settings
Hybrid : meaning it also works in modern browsers who have javascript disabled (no IE).
CSS : completely stylable using css
Javascript : uses unobstrusive javascript to drive the bahavior

Youngpup slideoutmenus uses a menu system in which u have to create the different menu items using js calls, much like JSCook does. This isn't semantically correct since the menu isn't available in the markup. My solution just turns an unordered list into a 2 level menu system. Turn off javascript and css and the links are still there. This is how it should work (http://www.mooss.org) !

Mambo could use the same approach for it backend and frontend menu's. Just provide the markup, a default template could use a similar approach as mine to create dropdown menus or u could style it in a completely different way.

This approach put's all the power in the hand of the template designer (where it should be), there is no need to hack any core files to produce a certain affect.

Jinx

November 21st, 2004, 09:33

Regarding to your last posts mr Jinx/Mambosolutions:
1. Yes, there is an issue with the loading time of the admin panel
2. Yes, it would be nice to have different templates, starting with 2 basics ones: text only, c-panel type (understand with icon images)
3. Yes js menu is bad. My question is why would we need any drop down menu solutions ?¿

1. This is certainly an issue if u want to improve the user experience
2. Also a solution to improve the user experience
3. U don't ! All depends on the context. I just wanted to provide an example how it should be done, so the desision if one needs a dropdown menu can be left to the user.

IMHO, the real issues are not really discussed in that post:

This is a real issue, it will influence the way a user deals with the backend. Navigation comes before workflow, functionality, content. What do you want here ? A navigation scheme that is the power in unflexibility and leave no options to the user in altering both layout and contents ? Or a a real flexible solution, that can be styled/changed to the users needs ? All other issues are dependant on the way u can handle navigation.

How much does the admin panel answer the needs of the user ¿? (understand functionalities)

Depends on what the users needs are, how are u going to determine those ?

Waht should be the main blocks in the admin panel ?¡ (understand process definition)

Again this depends on the context

How intuitive is the current admin panel ?¡ (understand overall navigation system)

Again this depends on what the users expectations are of the admin panel.

How can we leverage the learning curve impact ¿? (both for newbies & people coming from another CMS)

Learning curve for users/template designer/developpers ?

I will start a new post with User management suggestion, which is a post that is trying to launch in debate on that directionand not it's built, how can we make the layout nicer or more efficient ?¿ Let's not start the house by the roof

I'm not ! I'm talking about seperation between content and markup/presenatation/behavior. Mostly about the actual markup which provides us whit a good foundation to build the rest of the house on. The inner and outer decoration depends on a users needs/goals. Don't try to think i his place, but provide him with the flexibility to do his own thinking.

YTW

November 21st, 2004, 10:22

mambosolutions

November 21st, 2004, 10:56

i think in some way we are all close to agreeing on many issues here, like seperate code from presentation, give user flexibility to choose their level or style of admin layout. etc.

jinx: those menus you wrote are sweet, do you have them integartes in mambo in a template or module and can you send me an example?

Jinx

November 21st, 2004, 10:58

Fully agreed that it's a matter of context. In fact I would apreciate to see the official mission statement of the Mambo CMS product. I am thinking as if this product should tend to be used for masses, but it might be a technical goodie for a niche of experts too. 100.000+ downloads does not fit anymore with a niche positioning i guess. Anyway, this should be stated somewhere

I totally agree with u here, a priority for mambo should be to establish it's goals and priorities. T

I overall agree with the possibility to let the user customize the admin panel & its layout according to the user needs and tastes. And also that there is a load issue with the current admin panel. Let's try to define a kind of admin panel config file where the user could customized some functions:

Why would u want to put this in yet another config file ? This would add just more configuartion options to the mix. Make it simpel, create 4 different admin templates that just do this for u. What u need for this ? Well, again, sematic correct markup ! Why because, we are talking about layout here, not about functionality.

1. Choose admin panel template: C-panel (icon images) versus Text based (no images)
2. Enables drop down menus: Yes/No
3. Load help files: Yes/ No
4. Enable overlib script: Yes/ No
-....

1. Put images in css files and load the css file in the template if u need the images otherwise just don't load the css file.
2. If u use the concept i described in my previous post, this is the responsability of the template.
4. Again this is the responsability of the template, if it loads the js file the creates the overlib behavior or not.
....

Let us try to have a complete list, and then we will try to rank items. This is a very good exercise.

A list of what ?

But, again we are curing the symptoms not the cause
: arrow: There are up to 4 levels fo navigation in the current navigation system of the admin panel. We do have a problem of conception.

True, who has put them there ? :) This is another discussion. Where u place your navigation elements, depends on how u define the workflow. However 4 levels of submenu's are always bad !

If you want to discuss customization of the admin panel, I would prefer to have an option:

I don't want to discuss this, since it depends on my needs and the nature of the project. I just want it to be possible.

I am a total newbie and my site is a corporate web site with 5 pages, please make a simple admin panel for me

Again ... context ? conceptual model ?

A total newbie ? Define ?
Corporate website ? Define ?
Simple admin panel ? Define ?

It would be far better to try and answer the following question, which conceptual models does mambo need to accustom the needs of 70% of it's users ?

Jinx

November 21st, 2004, 11:04

jinx: those menus you wrote are sweet, do you have them integartes in mambo in a template or module and can you send me an example?

Thanks ! Visit this site (http://www.mooss.org) for an example. I don't have them integrate in a module and i don't need to. Integrating them in a module would break seperation of markup and behavior. However i have create a module that allows me to render unordered lists from the db. It uses domit to create an xml document from the menu items in the db, this xml document is parsed into xhtml. I just need to add one simple id to the menu and include the js file in the template and voila ... a dropdown menu system !

mambosolutions

November 21st, 2004, 11:17

:off topic :

thats nifty...could do a flash menu too with this system i have made a smile dynamic flash menu that pulls from the mambo database, outputs XML. load into flash, never tried using domit for that step----

how do you have this licensed( the slide.js )? can i use it on a template? Do you have a small tutorial? (that would be excellent)

thanks

Thanks ! Visit this site for an example. I don't have them integrate in a module and i don't need to. Integrating them in a module would break seperation of markup and behavior. However i have create a module that allows me to render unordered lists from the db. It uses domit to create an xml document from the menu items in the db, this xml document is parsed into xhtml. I just need to add one simple id to the menu and include the js file in the template and voila ... a dropdown menu system !

absalom

November 21st, 2004, 14:47

Nice work on the menus, Jinx.

I was looking at Youngpup's work to integrate it into Mambo a while back and came to the same conclusion - it wasn't semantic, let alone dynamic enough..

mambosolutions

November 21st, 2004, 15:09

:still offtopic:

me too.. i tore it apart and realized it was futile in its current form, definatley not ready for a dynamic system...with the x and y positions hardcoded etc..Jinx would be nice if you would share these menus with the community :) but as you already let me know you have decided not too :(

but thats ok, you're still ok in my book. ;)

Nice work on the menus, Jinx.

I was looking at Youngpup's work to integrate it into Mambo a while back and came to the same conclusion - it wasn't semantic, let alone dynamic enough..

Jinx

November 21st, 2004, 15:31

Nice work on the menus, Jinx.

I was looking at Youngpup's work to integrate it into Mambo a while back and came to the same conclusion - it wasn't semantic, let alone dynamic enough..

Thanks !

Guys, i'm not sure what todo with the menu system. U have to understand, it took me about 2 months to get them right. A second problem is support, the code is just too advanced to just share with the community. Users will be on my neck forever and ever, because ... this and that doesn't work. As long as u understand the system and u know how to use it, it works like a charm, but i don't see this happening with the everyday mambo users, especially since dropdown are such a hot topic lately.

mambosolutions

November 22nd, 2004, 00:53

:still off topic :

If you wanna release it, I will offer to make a tutorial how to implememnt it in a template- and I will make a GPL template to release to the community that includes both our credits. On the other hand if you want to keep it to yourself I completely understand and respect that. I know it wasn't easy at all to make it work-thats why I ended up doing other things because i saw it would take a huge amount of time.

Maybe we should continue this dialogue via PM-and let this thread back on topic - i have the feeling we have taken a turn down a side road...

YTW

November 22nd, 2004, 02:31

Let's try to summarize the latest inputs/questions (drop down menu appart):

1. It seems to be agreed that there are some issues with the loading time, the navigation & the overall ease of use of the admin panel
2. Some are pushing for introducing 3 or 4 different admin templates depending of the user needs & personal preferences
3. Some are pushing for reviewing the user needs & the process of the core admin panel to correct some conception weakness
4. Further separation of content and markup/presentation/behavior is required

Points 2 & 3 are not exclusive at all, the discussion is more centered around what should come first

:arrow: What are the Mambo project goals & targets. What is currently the current average user profile (needs & preferences) and/or what is the desired user profile. We're missing some inputs there. So i guess we need the dev team to go on with that discussion. Otherwise we can keep on discussing for ages, each one having its own idea of what Mambo is/should be.

absalom

November 22nd, 2004, 02:34

I'm thinking point 4 is a higher priority as the more you seperate content and behavior, the more it affects loading time, navigation and ease of use. How it gets implemented is secondary to the focus that content and behaviour should be seperated to increase speed.

MasterChief

November 22nd, 2004, 04:34

Comments on the above to help with the discussion (which I am enjoying and finding helpful, thanks).

1. Load time is a big issue. Some of the new framed layouts are trying to address this by note loading the whole admin layout each time you click.

2. If I was to pick 3 or 4 template I would choose, simple, simple, simple and simple. If we get the "simple" formula right there is no need for an advanced mode (hopefully).

3. Yes, the process of content production is a major concern. Basically, when you log into the admin, the 'content' view should be in your face.

Content should be the first thing you can maintain.

Second is ease of linking content to menu items.

Third is ease of user management and access control.

Fourth is an improved files (aka media) manager.

Each of these is important. If we can get a good formula for all of these all the other things fall into place.

4. It's in the pipe. There are some limitations with parts of patTemplate but assume that there will be a very strong MVC paradigm.

Goals: To re-balance the power we added to 4.5.1 with the simplicity of previous versions of Mambo. To focus more on the user experience of producing content. Make it simple and enjoyable.

Hope this helps.

Jinx

November 22nd, 2004, 06:53

Andrew,

Some remarks on your answer.

1. Load time is a big issue. Some of the new framed layouts are trying to address this by note loading the whole admin layout each time you click.

Framed layouts ? Are you serious, frames are deprecated in xhtml 1.0 strict and are replaced by XFrames (http://www.w3.org/TR/xframes/) in xhtml 2.0. I wouldn't go there, if u want to use an approach where u create statefull pages that only refresh part of it's content u can use html overlays (http://disruptive-innovations.com/zoo/20040830/HTMLoverlays.html), this is in fact a XUL technique but it has been adopted to html.

2. If I was to pick 3 or 4 template I would choose, simple, simple, simple and simple. If we get the "simple" formula right there is no need for an advanced mode (hopefully).

I don't agree with this. Is not so that if we get the 'simple' formula right there will be no need for other templates. It's just impossible to cover your complete userbase with one simple template. I believe u should offer around 4 templates, i think this could cover 70% of the conceptual models used by mambo's users. The other 30% are designer/developpers that are perfectly capable of creating their own backend template to suit their needs.

3. Yes, the process of content production is a major concern. Basically, when you log into the admin, the 'content' view should be in your face.

I totally agree, also the number of clicks needed to add content to menu items should be reduced to a mnimum.

Content should be the first thing you can maintain.
Second is ease of linking content to menu items.
Third is ease of user management and access control.
Fourth is an improved files (aka media) manager.

Each of these is important. If we can get a good formula for all of these all the other things fall into place.

You are talking about functionality here, it's not per se because you have the functionality there all other things will fall into place. It's the whole of conceptual models, navigation scheme, functionality, workflow, ... in short 'user-centered interaction design'. All those need to fit.
About the media manager/file manager, what are the plans/idea at the moment ?

4. It's in the pipe. There are some limitations with parts of patTemplate but assume that there will be a very strong MVC paradigm.

Great ! I hope this will also happen on the frontend ?

Goals: To re-balance the power we added to 4.5.1 with the simplicity of previous versions of Mambo. To focus more on the user experience of producing content. Make it simple and enjoyable.

What about the long term goals ?

YTW

November 22nd, 2004, 09:30

Ok let's try to define what could be the embryon of a user experience study for 4.5.2

Improve user experience for 4.5.2

Goals:

To re-balance the power we added to 4.5.1 with the simplicity of previous versions of Mambo. To focus more on the user experience of producing content. Make it simple and enjoyable.

Priorities for the admin panel conceptual models:

1. Content should be the first thing you can maintain.
2. Second is ease of linking content to menu items.
3. Third is ease of user management and access control.
4. Fourth is an improved files (aka media) manager.

Performance improvements:
1. Reduce load time: Overall + Enabling options (help files, overlib, navigation, etc...) if it is proven to have a real impact on load time
2. Further separation of content and markup/presentation/behavior is required (introduce tempaltes for back-end ?¿)
---------------------------------------------
My answers:

Point 1 & 2 are the same issue for me. I don't understand the current content production process in Mambo, with a useless separation of content & menuing. Suggestion: Go now for a full Node Base System, allowing multiples categories and seamless creation of menu items. Your categories & Items defines your menu. That's it

Then you say: 1. Content should be the first thing you can maintain.
Well in that case, that's what should be apparent just after the user has logged the admin panel. I would second that the first page after the loggin should be a descriptive page with text where it is presented all what can be done with the admin panel, and then finishing with a big button/flag that says START CREATE CONTENT NOW (visible with no scroll down for any screen resolution). That would obviously guide the user to what's he needs to do first.

Point 3:
Thre is a post (http://forum.mamboserver.com/showthread.php?t=22780) specially dedicated to User Management feedback. Your answer has been that mostly it's on the pipe/road map, and for the moment no interest in the details (framework assessment first). I will join Mr Jinx in saying that enabling a functionality is not enough for me, and that the way it will be enabled and implemented is according to me as much important as what this functionality can do for the user. So I would be keen to spend more time on the details of how the new user management will be implemented, and make sure that the implementation will match with the conceptual definition.

Point 4:
Are your refering to a performance issue there ?¡ The major improvement I could think about the media manager would be to allow a "drag & drop" feature. See all your media elements organized as a dynamic tree, and grab the one you want directly in your content.
Please provide us with more info about what are the issues with the current media manager.

I would add two points that you are not mentioning, but that would definitively improve the "newbie" user experience:

1. A migration wizard: At the end of the install process, offer the possibility to fully guide the migration to mambo from a simple static html web site (5 or 6 pages). It's an idea I have shared few week ago with Stingrey, and that I think that it could be further explored. A must for newbies to leverage learning curve effect, a non bothering option for the rest of users

2. An instant custom of the layout I do think Mr Jinx is right in saying that Mambo should offer some customization features. But for me the priority nº1 are the front-end templates (See the results of the poll (http://forum.mamboserver.com/poll.php?do=showresults&pollid=144) you have set-up). The default templates provided are really good looking but are complex to customize. The idea would then be to add to the current default templates, a single fully customizable simple template:

Default layout: header+ horizontal nav + 3 columns (modules on left & right, main content in the middle) + footer

Offer the possibility to customize the layout via a component wizard (a basic form):
--> variable width or fixed width
--> left sided or centered
--> 3 columns/2 Columns Left sidebar/2 Column right sidebar/1 column
--> A set of x differents colors, or better look & feel (x=5 to 10)

That's a very basic excercise with CSS based layouts, you only need to provide the template mark-up (the same for all verison of the layout), dynamically write the CSS according to the user selection, and you're done.

See an example (http://www.dotclear.net/themes/) with the same mark-up and still very different look & feel

If you decide to go with that solution, i would also recommed to add a second button/flag CUSTOMIZE YOUR LAYOUT NOW along to the previsouly mentioned START CREATE CONTENT NOW.
-------------------------------------------------------------

That's all for today folks, I need to work a bit

MasterChief

November 22nd, 2004, 14:07

@frames

If you look in the CVS you'll see I'm using iframes, not framesets. Is that what you are worried about

@ 3-4 templates

The underlying logic has to be simple but that does not prevent you from presenting a diffent presenation layer. Thinking out loud, I'm not in favour of the core having to work out what is basic and what is advanced more, but there is no reason why a templates can't be used tuned for different skill levels. Is that what you meant?

@ Media manager

Frankly it's woeful. You cannot maintain everything you need for the site and it's traditionally been tuned towards imagery. Basically it needs to be upgraded to a more traditional file manager. There might be libraries we can borrow or else we built it ourselves

@ MVC

Yes, frontend as well.

@ Long term goals

We are working on them.

@ Node/Object based system

It's already happening. The 'folders' will be the only set of 'categories'. Menus will be sybolic links to what is in a folder.

More later...

Jinx

November 22nd, 2004, 14:46

@frames

Iframes pose the same problems, there are not valid in xhtml 1.0 strict. Like i previously mentioned there are other/newer ways to handle this. I'm currently working on folder like system to present docman's multiple level categories. It will use xml-rpc and overlays to reload only parts of the page when a folder/file is selected in the tree. This way u create statefull pages.

@ Media manager

Basically it needs to be upgraded to a more traditional file manager. There might be libraries we can borrow or else we built it ourselves

Maybe some form of docman integration could be possible ? Just an idea.

MasterChief

November 22nd, 2004, 15:16

@frames
I'm no expert but we are using 1.0 transition which does support an iframe?? But, email me some reference information and I'll look into xframes and such.

@MM
Interesting idea. Could certainly devolve more or the file handling functions to the core. Then DocMan can just worry about storing meta information and presentation. I'd like to look at secure folders as well. Those are ones where we rename the file when we store it. Currently you can bypass any security if you know what the file name is. Just some ideas...

Jinx

November 23rd, 2004, 10:17

@frames
XFrames in't a valid option yet, there isn't any browser that supports it. However studying the topic will give u a good idea about the do's and don' of frames. I'm not a fan of using frames, they can however give u a speed increase and if u go this way iframes are the better option.

@MM

Interesting idea. Could certainly devolve more or the file handling functions to the core. Then DocMan can just worry about storing meta information and presentation. I'd like to look at secure folders as well. Those are ones where we rename the file when we store it. Currently you can bypass any security if you know what the file name is. Just some ideas...

True, but we don't want to use a file renaming concept. This breaks the ease of adding and deleting files using ftp. Our users seem to greatly value this. If a user wants more security he can always move hos documents folder below the http root.

Currently we are working at a sort of allow/deny access docbot (http://www.mambodocman.com/index.php?option=com_simpleboard&Itemid=30&func=view&id=2548&catid=505&limit=6&limitstart=6) for docman. This will provide even more security.

In 1.3 we have completely modularised docman's code, it wouldn't be too hard to merge some classes into mambo. In a next version we will integrate pear's VFS (Virtual File System- package) originally created for the horde framework to provide more abstracion for handling files using different protocols.

MasterChief

November 23rd, 2004, 15:18

VFS! THANKYOU. This is what I've been looking for.

mambosolutions

November 23rd, 2004, 15:28

does that mean that in the next version of mambo all servers will need to have php compiled with PEAR for Mamboto run? ( I know the latest php has it already) just curious.

MasterChief

November 23rd, 2004, 15:42

does that mean that in the next version of mambo all servers will need to have php compiled with PEAR for Mamboto run? ( I know the latest php has it already) just curious.Um, well, I couldn't say for sure. However, I've always been careful with the way I use anything out of PEAR. Usually try and stick to standalone stuff (cf, Cache_Lite).

There's nothing magical about PEAR, it suffers the woes of any 'forge' having well and poorly designed and maintained libraries.

Jinx

November 23rd, 2004, 18:29

VFS! THANKYOU. This is what I've been looking for.

I doesn't happen very often, but sometimes I actually bring on good stuff, consider it an early christmas gift ;)

does that mean that in the next version of mambo all servers will need to have php compiled with PEAR for Mamboto run? ( I know the latest php has it already) just curious.

No not necessarly, the VFS package only depends on the pear error package. Besides this it works perfectly standalone. I think we will write our own error handlers and so there is no need to install pear.

YTW

November 23rd, 2004, 18:52

Good to see that this discussion has positive outputs !!!

Are we still talking about User Interface & ergonomy ?¿ ;-)

absalom

November 24th, 2004, 02:12

VFS, iirc, is more the technical side of implementation, but yes.. I think so.

Jinx

November 24th, 2004, 04:54

Good to see that this discussion has positive outputs !!!
Are we still talking about User Interface & ergonomy ?¿ ;-)

Maybe time to get the discussion back on track. Maybe we put a synopsis of this discussion on a private page on the wiki (docs.mamboserver.com) ? This would increase the productivity of the thread. What u guys think ?

mambosolutions

November 24th, 2004, 05:05

I don't see how putting a synopsis in another location will increase productivity of this thread to be honest. In my view, this is more or less a 'brainstorming' thread...some good ideas and dialouges taking place. So the question to be answered in my mind that since we seem to be self moderating this thread a s the contributors to this topic, what is the actual means of acheiving some kind of 'concrete results' from all of this...it is basically up to Andrew/Ray to decide what is going to happen right?..

If i misunderstood your intent excuse me...

Maybe time to get the discussion back on track. Maybe we put a synopsis of this discussion on a private page on the wiki (docs.mamboserver.com) ? This would increase the productivity of the thread. What u guys think ?

Jinx

November 24th, 2004, 07:17

YTW

November 24th, 2004, 07:48

understood Mr Jinx, good point.

For the rest I am affraid we have scared Andrew, or maybe he has gone to go & get more dev team troops to attend our user centric ramblings :)

stingrey

November 24th, 2004, 08:09

Yes, but some interesting things have already been discussed here, if u summarize this and put it together in one location u avoid the change of repeating this whole conversation again, but then again it depends on what the core team wants todo with the information.I have nothing against putting a brainstorming session down in a wiki for a consolidation of ideas. I thinks its a good idea

Andrew and I have already done this in a few cases to help our private brainstorming sessions.

======================

For the rest I am affraid we have scared Andrew, or maybe he has gone to go & get more dev team troops to attend our user centric ramblings Actually its way past Andrew's (and my own) bedtime.

I've been meaning to post my thoughts on the excellent points brought up in these discussions, but everytime I go to do it, you guys and more stuff for me to read :mrgreen:

MasterChief

November 24th, 2004, 15:35

Someone distracted me by sending me a soundtrack AND cheesecake, hehe. Sorry, I just have to pick and choose when I weigh into discussions as my time is suddenly being used up more rapidly :)

Jinx

November 28th, 2004, 10:00

Hi guys,

To continue this thread ...

Let's talk about content items and images. I find it rather difficult to add images to content items with Mambo. The way it works now by adding the {mosimage} text tags isn't the way things should work. It goes completely against the concept of a wysiwyg editor. Yes, a user can use the preview btn to see what he is doing, but he should be able to view his work right inside the editor.

The original idea was to untie an editor completely form Mambo. Giving users the possibility to install any editor they wanted. This is a nice goal to strive to but i don't believe it's a realistic goal. Over time lot's of editors have been adjusted to work better with Mambo, not only because the editors themselves had/have several bugs but also because they needed to fit better in Mambo's UI.

I believe Mambo should leave this ideology behind and move to an interaction based concept. I'm not saying Mambo should restrict itself to a set of predifined editors. It should just create a way to let an editor interact with it.

For example, Mambo could expose certain UI events to editors using javascript. Editors can react on these events by changing their content, in the case of images, adding the image, based on parameters passed to them. U can think of this concept as 'a kind of javascript mambots'. Mambo exposes a set of js-events and leaves it up to the editor to implement the events or not.

Most editors used in Mambo today have the necessary power to handle this kind of concept. It will certainly be a feature the user will benefit from and actually not so hard to implement.

Cheers,

Johan

MasterChief

November 28th, 2004, 15:05

{mosimage} was originally developed because many of the W-editors at the time hijacked the relativel URL that we created and turned them into absolutes (eg, http://localhost/...). This was fine if you didn't move your content or your server paths, but if you did...

Maybe someone should start a thread like "Is mosimage a sacred cow". My feeling is that it might be a fairly vocal discussion, however, I don't disagree with the points you make.

tonyskyday

November 28th, 2004, 18:09

Maybe someone should start a thread like "Is mosimage a sacred cow". My feeling is that it might be a fairly vocal discussion, however, I don't disagree with the points you make.

There have been discussions in the past about making the mosimage more WYSIWYG, but i don't think any of you devs participated. It would certainly be an interesting discussion.

YTW

November 29th, 2004, 01:22

images in text: Drag & drop from the new media manager & visible directly in the text (no preview needed)

general: There are many new features coming up in 4.5.2, which are good for improving User experience (keep an eye on learning curve). I Just hope that when it comes to the details of implementation there will be a real discussion/thinking about the interface design & the process.

eyezberg

December 7th, 2004, 03:38

There have been replies to this before, but as I just read the whole htread, I'd still like to voice an opinion..

3. Yes, the process of content production is a major concern. Basically, when you log into the admin, the 'content' view should be in your face.
Content should be the first thing you can maintain.
Second is ease of linking content to menu items.
Third is ease of user management and access control.
Fourth is an improved files (aka media) manager.
Each of these is important. If we can get a good formula for all of these all the other things fall into place.

Content view: just have a look at the default Textpattern interface when you open admin: WRITE!
I do not agree with putting media manager fourth.
Media elements (images, swf, files..) are inherent ingredients of content, so should be equally important/accessible! Points 1,2 & 4 should all be dealt with together.
As to point 3, well this really depends on Mambo's main objective, "the official mission statement " as YTW put it: is user management considered as an important part of the CMS (C as in CONTENT..!) or not, is it going to be more focused on Communities, Business, Portals, ... whatever, or a mix of everything.
I can use Mambo for a site without ever needing any user-related features...
As has been said before in this thread: where are we going? This could also influence on what kind of backend(s) should be included..
Two minimum (simple/advanced) I'd say. Then use access level checks in the admin to show or not certain links to your clients when they maintain the site's content, via the template...easy.
2€-cents.. nice thread ;) nice menu, Jinx! (sorry, catching up on this..)

modus

December 8th, 2004, 13:20

"This app sucks, because" I just read this whole thread and would like to throw in some random thoughts from a baby mamber perspective. :shock: Please excuse if some of my points might have been posted in other threads, I think a wiki could do a really great job here.

0. Installation was easy - after my provider had nodded to all the requirements.

1.1 The default buttons in the admin interface were the first thing i didn't get - just because they are greyed out - my first impression was: how do i accomplish a task, when none of the possible actions are available to me? I have grown used to grey items as being deactivated.

Another really bad thing about grey icons is that they are less distinguishable, because of the complete lack of the colour information layer - far from intuitive. Used the other way round this concept would make much more sense. And as we grow older they might well become too grey to spot a difference soon ;)

1.2 Icons are a tool to accomplish tasks intuitively. Therefore they should be distinctive. The icons in the admin area are generally too complex in my view. Maybe it's just because i don't get the link between a folder and publishing or unpublishing a document on a website (of course there's a connection if you think in terms of a database, but a document usually is something different than some strings in an array and what about that globe then if you follow this logic?).

Icons should reflect their function more than the OS they were inspired by. If you have to think about an icon's meaning, it actually is more an illustration than an icon. Therefore icons should be kept as simple as possible, like a logo.

1.3.1 The small 'Published'-icons in content are way too complex and could be replaced by color-coded dots or pages with symbols, but not with the same icons as in the 'Frontpage' column, to keep them distinguishable in case you have to scroll. Alternatively the table header could be static, so you could use the same icons.

Their definitions on the bottom of the page should not use underlined text, if it is not linked to something.

[ :idea: Having the possibility to filter documents in 'All content items' by status, would be useful, in case you have a lot of authors and documents to deal with as an editor.]

1.3.3 Little consistency flaw: In some of the areas (e.g. the Menu and Mambots Managers) the text labels appear right from the icons instead beneath of them.

2. Whenever i save a task in the admin panel, the next page i see is a) the same page (if it was a list) or b) the list page (if it was an item). This is not true for the main configuration, which takes me back to the default page. As there is no hint, if you can browse from tab to tab to save your changes at once in the end, users might tend to save on every single tab, which makes this behaviour annoying. Besides, it's inconsistent.

3. What I truly miss about Mambo is better documentation and user experience. What do I mean by this, as a lot of information obviously has been gathered?

3.1 The difference between mambots, components and modules should be clearly explained for dummies somewhere right from the start, as this is part of the core concept of mambo and one of the most confusing things about it at the same time.

In RL a component and a module are quite similar things, which insiders tend to forget after a while. If you start browsing mamboforge in order to check out the potential of the 'easiest CMS', you find modules and components of the same name and start asking yourself, if you need both of them (why aren't they linked or offered in a package then?) or if you can choose whichever you like (but then what's the difference?). :?

And what is a bot - how much more automatic is a bot in the context of a CMS than the CMS itself? Sorry guys, this is really weird. Of course not anymore from a dev's perspective, so speak plain text and we'll be able to share your point of view. Try to explain it to your mother, father, wife or children (given their not a geek like you ;) ).

3.2 The same applies to the concept of sections and categories. You could easily take one for the other and it still made sense.

3.3 Most sites related to mambo i visited were published in the same cryptic fashion: before you even get to know what they are about, you're presented a version history or some other technobabble. Unfortunately there is no other page where you could get some info on the offered mambot/component/module in sight.

Devs should start to have a look mambo as kind of a shareware - in terms of documentation - people are used to find a readme with a short description of the tool's capabilities, a short manual including setup instructions followed by a version history for those already familiar.

3.4 I wonder why i have to register on every *@#%! mambo-site, just to have a look at its forums, documents or downloads. I sometimes stopped looking further just because i got fed up of another registration process on mambothis or mambothat, just to find out what a tool is about and if it could be useful to me. Is anybody making money on email-adresses here? :?

3.5 Does this huge amount of relevant information have to be scatterd all across the web? Couldn't there be a real mambocentral and every developer could publish his own site with the same information somewhere else? Redundancy is not a shame. In an ideal world an information published by a developer on his site would be distributed to the central as soon as possible (think downtimes) or vice versa. Link each developer's site as much as possible and give him all credit due, but keep me user from searching and registering so much, please.

-----------------------

Note on the last 3 points: If THE BIG GOAL of mambo really is to provide THE EASIEST CMS, maybe this community should come up with some kind of 'un-corporate identity' and some gui-delines to follow in order to provide a better user experience.

-----------------------

4.1 When it comes to menus, i think there should be at least an interface, that displays the actual menu you are working on. 'Top menu' might be intuitive, but 'main menu' (which on a lot of sites equals the top one), 'other menu' and 'user menu' are hard to get. And as it is far from obvious, what happens when you rename, delete or add a new menu, there could be some more hints in the help pop-up, even if it was RTFM on this with a link to the online version, e.g. on inserting it into a template, styling it etc. It would be nice if you could edit their appearance right here, though.

4.2 Concerning dropdown menus i think they are one of the greatest tools to provide a rather complex navigation in the smallest space possible. They are perfect to let your users learn about your site structure without having a look at a sitemap at all and make it possible to offer every page on your site just the magic 3 clicks away (provided you set up a clever architecture). And finally, people are used to them, they work with dropdowns in nearly every single app, even their browsers.

5. Which leads me to a last idea: Wouldn't it be nice, if you could experiment on the styles of a - sorry, not sure of the right mamboterm - section (intro, main text, links, menus, ...) in a real templates editor? This way you didn't have to set up a local system or upload the template with every change. I imagine kind of an optically framed version of a page on the left. Clicking on an item reveals its styles on the right. Clicking a style on the right then highlights all the places in that page where that style is used (as a warning, what to expect by changing it). You can then create, duplicate, edit and assign classes on the right or change existing ones. In the end you can save your changes as a new template and choose to apply this one in favor of another one.

Down to earth.
Enough for today.

Don't feel personally attacked, if your site/project fits one of those mentioned - i tried to stress my feelings on my journey towards this community, so you might get an idea of what problems arise for a mambo-newbie - even with about 10 years of experience on the web, creating websites for some years now, but without much experience with or knowledge of CMS/SQL/PHP. Your perfect target - stupid, but ambitioned.

And if some of the features i ask for are already in there and i just didn't find them, yet, please throw in a number and RTFM for me.

mambosolutions

December 8th, 2004, 16:01

Let me say Thanks for taking the time to give that feedback, I sincerely hopr that the effort on your part has some positive effect in terms of motivation for the dev team on the next incarnation. As far as the knowledge and opinions that I carry in my bag, i would say that most of your points are on target.

mambovince

December 8th, 2004, 17:18

I agree with mambosolutions modus, absolutely spot-on points you have raised!

Vince

Jinx

December 8th, 2004, 19:43

Indeed, no remarks to be added here. A nice rundown of problems. :)

MasterChief

December 9th, 2004, 16:16

Thanks for your comments modus. This is what I consider 'good' feedback.

Most things are noted or in the works to be changed but I'll comment on a couple of points:

1.3.1 Coloured dots don't work for people with colour blindness, that's why we go for different 'shapes'. That said, I open to ideas for a better combination of shapes.

3.1 Is the glossary not enough? Now, here is my hobby horse :) We get challenged on jargon, BUT, I get very little useful alternatives/solution in return.

Mambot = a small or possibly large piece of code that can be triggered at some point within the running of the script to either modify and object, it display or perform some other function altogether (like logging)

What do you call a 'mambot'? A pluggin, an addon, an vital organ, heart, brain, nervous system...it's just more jargon where ever we turn.

At some point you *have* to learn jargon, eg, web, applet, html, the net, flash, etc, etc. Then there is simpler stuff, template, component, module...there is just no standard that we can reference that helps us determine 'things' that make us both the business logic and the presentation layer (Andrew steps off his horse now).

I'm really open to ideas here...but to date a glossary is the only thing that seems to satisfy the problem.

3.4 I don't think we can solve this problem...it's universal for the web in general and/or the preference of the site master.

4.1 This is a difficult one because of the variation afforded in template design. I'll see if we can expand the context help for this (click the 'grey' help icon).

5. Yes it would be nice. It would be technically quite challenge and I wouldn't see it as unreasonable to expect to pay for it given the business benefit is would afford.

Again, thanks for your input. Unfortunately 'the next guy' will turn around and say the exact opposite from their frame of view. It makes it very hard for the poor dev to work out what is the middle ground that will satisfy the most people ;)

modus

December 11th, 2004, 20:03

1.3.1 Coloured dots don't work for people with colour blindness, that's why we go for different 'shapes'. That said, I open to ideas for a better combination of shapes.

I agree, you could use the icons from the 'Frontpage'-Column as general indicators if a page is published or not, for the frontpage use an iconic representation of just that, crossed out, if not intendend to be seen there. The problem here are users that might already be stuck on the actual meaning. But concerning the actual icons: their state can (at least on my screen - 1280x854) only be recognized by coulour-code, shape is near nada.

3.1 Is the glossary not enough? Now, here is my hobby horse :) We get challenged on jargon, BUT, I get very little useful alternatives/solution in return.

Mambot = a small or possibly large piece of code that can be triggered at some point within the running of the script to either modify and object, it display or perform some other function altogether (like logging)

What do you call a 'mambot'? A pluggin, an addon, an vital organ, heart, brain, nervous system...it's just more jargon where ever we turn.

At some point you *have* to learn jargon, eg, web, applet, html, the net, flash, etc, etc. Then there is simpler stuff, template, component, module...there is just no standard that we can reference that helps us determine 'things' that make us both the business logic and the presentation layer (Andrew steps off his horse now).

I'm really open to ideas here...but to date a glossary is the only thing that seems to satisfy the problem.

I totally agree, but I'm not attacking jargon as such (isn't any language anyway?). I described my way towards mambo, so what i mean is that jargon should be explained very early in the project description or the faq, maybe by linking the term in full text to an online glossary, so all in all first timers can adopt to the concept faster. You just don't download 10 CMSs to install and test them, you don't read 140 pages of a manual, you like to find as much clear info as possible beforehand, to see if this one CMS finally fits your needs and you think you'll be able to learn it in a reasonable amount of time (consider typo3, cough).

My point is that the sites are still somewhat cryptic and therefore people might overestimate the effort needed to learn this.If you get the basic info right from the start, the overall feel becomes much easier even for less geeky types. Maybe it would even be nice to have something like 'pros and cons' somewhere.

3.4 I don't think we can solve this problem...it's universal for the web in general and/or the preference of the site master.

I think, sometimes it's enough to raise a topic on behalf of a common goal. Sure some will get it and some won't mind at all. But the overall feel might change. That's why i came up with 'styleguide' and 'CI'. If you state a common goal (here: easiest CMS, so many more people should be using mambo, ... [special interest here]) and arguments, more devs might get it. In my view a lot of devs maybe just get accustomed to do their own research and rarely feel uncomfortable when fiddling around with their code, systems or sites. With users it just the opposite - they're happy if something works out-of-the-box and let's them concentrate on their work. Problem is, those dummies are the same devs want to attract :)

Again, thanks for your input. Unfortunately 'the next guy' will turn around and say the exact opposite from their frame of view. It makes it very hard for the poor dev to work out what is the middle ground that will satisfy the most people ;)

I think it's choice, e.g. there's a very nice yet simple feature in OS X: you can customize the title bar of your finder windows, which turns out to be a real time-saver. There's a core frame given for basic operations, but you can choose to show or hide other elements as you like, even add your favourite tools to it (but i guess we don't need that one here).

As inmy post before, I imagine a representation of the actual state of an interface on one and the full set of controls on the other side of a window. where i can choose what to show or hide. Add the link to this function to every interface (as long as it makes sense) and it's always at hand. If then the admin could define which controls a user could generally use, show or hide, that would be perfect.

let 'em come.

-----------

Anyway, thank you (all) for your great work. I'd really love to see this project bloom and that's why I like to throw in my cents.

the same guy

tonyskyday

December 11th, 2004, 20:47

The only thing I'd add to the jargon discussion, is that part of the problem in explaining what a "mambot" is, is that the mambot feature has been evolving. It seems to have settled down, and it would be nice if someone could come up with a succinct description that can be shown to new users.

pagerefiner

December 12th, 2004, 01:08

In my view a lot of devs maybe just get accustomed to do their own research and rarely feel uncomfortable when fiddling around with their code, systems or sites. With users it just the opposite - they're happy if something works out-of-the-box and let's them concentrate on their work. Problem is, those dummies are the same devs want to attract :)

Exactly! In most marketing courses, the need to understand the needs and wants of your customer audience are heavily stressed. The quality of a product is in the eyes of the beholder. If the product is intuitive to use and works as stated, the customers feels they made a good choice and the product is perceived to be of high quality. The opposite is true if the product is not intuitive to use or does not work as advertised. Exceeding a customers anticipations should always be in the back of every developers mind. If you can continuously exceed the expectations of your customer, you have a customer for life.

pagerefiner

December 12th, 2004, 02:30

3. What I truly miss about Mambo is better documentation and user experience. What do I mean by this, as a lot of information obviously has been gathered?

I'm currently working on a 4.5.1 project for mmx with orion7 and konlong. We also have a 5.0 project in the planning stages. What's interesting about this project and its successor project is that documentation is at the top of the priority list. As new features are added, they have to be documented before moving to something else. We're responsible for writing a rough description of everything in our own words while it is still fresh in our minds. This is later polished by techdoc. They ask questions if we were unclear in our descriptions. We are also using tooltips more agressively in an effort to prevent the user from using the help system (less mouse clicks and frustration).

This has been a wierd experience for me because it's exactly the opposite of how most development teams handle this--documentation is more of an afterthought on most projects or a separate effort taking place in parallel with the development effort. There is collaboration in the two efforts, but not as much as we are witnessing on our project. Our techdoc person in there with the rest off and hounding our heels if we forget.

Because of this, we are acutely aware of the frailties in the existing help system and just started to build a new one for our project based on some MS Windows ideas. We are making an attempt to introduce multilanguage, context-sensitive help into our project. It's a bit early to tell where this is going yet, but the feature list looks promising. We use a variant of the Mambo content model with integrated multilanguage support, so doing something like this is bit simpler for us. This would not be a problem for Mambo 5.0, I believe.

The help system will work in the frontend or backend. We plan to have a module for the frontend with a sentence like "Click here if you need help using our site" and include help options elsewhere (footers, menus, pages, etc.). In addition to help topic matter in the backend, mmx has us working on some wizard-like interfaces for troubleshooting a problem. For example, configuring a store to work in a specific geographic locale.

I read Andrew's comments about color blindness with interest. I myself am partially red-green color blind, sort of an oddity for ladies but it happens. Color blind people can see colors and are at home working with them. What we see is just a bit different from what non-colorblind users see. Using subtle tints of the same colors in an icon or something like a adjoining tints of light red and green is where the trouble starts. If there is a clear distinction in color densities, it should be OK! If you used four-color images as icons, why not because color blind people look at them every day with limited color perception problems--they may not know what certain colors are but they can see distinctions in them (not always but mostly).

I would agree with Andrew that a well thought out, extensible glossary system is going to solve a lot of problems.

Always using the term option in documentation when selecting any sort of element, field, icon, menu items, etc. might be a good solution. Developers need to know the differences in elements, but Users just want to get from point A to point B in the quickest time. The user frustration element should always be kept in mind when developing or building anything--if it takes too long to learn or use they will go elsewhere.

There are some good editorial and style guides available in book stores. Sun, IBM, Microsoft, Oracle, etc, have all published technical communication guidelines that might prove useful as the basis for establishing some standards for Mambo. On our project, we are using the Microsoft Manual of Style for Technical Publications, ISBN 1-57231-890-2. IBM guidelines are similar. These guides cover software usability, so they are proving to be useful.

fcassia

December 12th, 2004, 02:51

My two cents... I've been playing with Mambo for less than 24 hours and here's what I found extremelly annoying (among lots of pleasant things :):

- You are adding a new contact, a new story, WHATEVER that features a drop-down "image" selection, to select among the images available on the site (on MediaManager or file manager or whatever it's called, -I'm still catching up on the names ;).... and.... you realize that the image that identifies that contact/article/whatever has not been uploaded yet. So you have to go back to filemanager/mediamanager and UPLOAD THE IMAGE, then GO BACK and do the entry submission. Why not add a "upload new" button on EACH FORM that has a "Select Image".... drop-down? It should be RIGHT NEXT TO THE "Select image" drop-down....

Just an idea.... :)

Second question... the bugtracker was mentioned... where is it? url?

Thanks and keep the great work.
Fernando

pagerefiner

December 12th, 2004, 02:58

Second question... the bugtracker was mentioned... where is it? url?

I think I saw an option for it in one of the forums, but I got in there the other day from the Mambo 4.5.1 project on the mamboforge. There is a Tracker tab for accessing it.

Nice touches as you mention are the kinds of features that make a user want to stick with a particular application.

mambovince

December 12th, 2004, 06:16

Exactly! In most marketing courses, the need to understand the needs and wants of your customer audience are heavily stressed. The quality of a product is in the eyes of the beholder. If the product is intuitive to use and works as stated, the customers feels they made a good choice and the product is perceived to be of high quality.
This has been a wierd experience for me because it's exactly the opposite of how most development teams handle this--documentation is more of an afterthought on most projects
Here's a suggestion that I normally promote when involved with deciding and implementing similar applications; CRM systems, etc...

Before writing ANY code, write a draft user manual from research of user needs. Everything from features, and most importantly, how they would actually expect to 'use' the product.

Get them to tell you what they expect the 'clicks' and 'screens' to do, and base the draft user manual on this.

Then, start planning the code so as to achieve the user expectations. Hence not an afterthought, but a roadmap created by user expectations = successfull product.:idea:

Vince

eyezberg

December 12th, 2004, 06:30

I think this thread here should be considered as the basis for building Mambo 5!

It's getting better and better, new people droping in with basically a sum-up of all newbie problems (AND suggestions on how to solve them http://forum.mamboserver.com/images/icons/icon14.gif ), thanks modus!
Other (thanks, pagerefiner) contribute personal experiences about color & help systems, from real-life usage AND developpement, what could be more usefull than that?
Then, a new user (thanks, fcassia) suggests something so simple and obvious, which is untill now handled only, with quite a few problems, by some advanced editors (which do not come installed in standard Mambo setup!): add an upload option for images next to a new article, just like here on the forums: add
Upload File
Valid file extensions: bmp gif jpe jpeg jpg pdf png
and that's it.. (or better: option to create a new, dedicated folder first..)
I'm now used to having the "images" folder open in FTP while writing articles, so any missing image is drag'n'drop, but you still have to save the article and reopen for the new image to show up in the list(s)!

About the beginner/advanced interfaces in admin, which could be solved by a one-click template change (ok,ok, what's "beginner", what's "advanced".. no need to split hairs, right?): many issues can indeed be solved by good icons which not only illustrate something, but carry a distinctive, recognizable, meaning our users are used to from other apps, more consistency (drop-down/tabs/icons/...), personalization OPTIONS (provided, but not necessary to use Mambo) etc..

Good thread!

Jinx

December 12th, 2004, 08:50

About the beginner/advanced interfaces in admin, which could be solved by a one-click template change (ok,ok, what's "beginner", what's "advanced".. no need to split hairs, right?): many issues can indeed be solved by good icons which not only illustrate something, but carry a distinctive, recognizable, meaning our users are used to from other apps, more consistency (drop-down/tabs/icons/...), personalization OPTIONS (provided, but not necessary to use Mambo) etc..

I have to disagree with you here. We never actually talked about beginner/advanced interfaces that can be switched with a single mouse-click. Like already said earlier, different users need different things at different times. It not upto Mambo to decide how a user will use the admin interface, this all depends on the users conceptual model. I believe this is a decision a template designer/mambo developper should be able to make.

I realise that lot's of mambo users want to use it straight out of the box, site developpers and commercial firms just want the opposite. They want real code flexibility to tweak things, whit a minimum in investment.

Taken this into account, 'Mambo's power in simplicity' creates a paradox. Simplicity for who ? The 'out of the box user' or the 'developer/designer' ? Both, that would be ideal, ... accomplishing this will be like dancing the mambo on a very thin cord. :)

pagerefiner

December 12th, 2004, 13:52

eyezberg

December 12th, 2004, 15:22

I have to disagree with you here. We never actually talked about beginner/advanced interfaces that can be switched with a single mouse-click. Like already said earlier, different users need different things at different times. It not upto Mambo to decide how a user will use the admin interface, this all depends on the users conceptual model. I believe this is a decision a template designer/mambo developper should be able to make.

I realise that lot's of mambo users want to use it straight out of the box, site developpers and commercial firms just want the opposite. They want real code flexibility to tweak things, whit a minimum in investment.

Taken this into account, 'Mambo's power in simplicity' creates a paradox. Simplicity for who ? The 'out of the box user' or the 'developer/designer' ? Both, that would be ideal, ... accomplishing this will be like dancing the mambo on a very thin cord. :)
Yes, we (I) did earlier on: Two minimum (simple/advanced) I'd say. Then use access level checks in the admin to show or not certain links to your clients when they maintain the site's content, via the template...easy.Mambo wouldn't be deciding.
First (simple) template shows prominent links to tasks such as "create Section/cat/new article".. (remember, CONTENT!! ) for the "out of the box", content adding persons with the other admin stuff hidden.
The "normal", full-featured interface for site managers (CMTs, Users, Settings..). Why would we need simplicity for developpers and commercial firms [..]. They want real code flexibility to tweak things..? :)
Often, I'm really just in admin to write articles, so a simple, quick access to each cat/sections/unpublished item would be welcome..

Now, If Mambo tracked user participation like a forum, it's a good gauge for appoximating a user's level of expertise. I can't agree to, because a forum tracks posts, what kind of "participation" will Mambo track? Time spent online in backend, number of articles writen, sections created, menu entries..??

pagerefiner

December 12th, 2004, 16:43

Not all forums. When you get down to it, there is a lot of click counting or clickthroughs (as the user passes from one point to another point on the site) because the more complex forums (or rather BB like systems) often evaluate participation based on access to other site areas (downloads, uploads, galleries, poll participation, etc.). The distinction between a forum, CMS, and portal is getting really murky because they are all trying to do similar things in order to expand their user audiences.

My comments were also directed toward the use of Mambo in a community site environment, not so much in a corporate internet or intranet environment. There might be a case where it would be wise to have preconfigured sets of configuration parameters designed to handle different environments. The user interface could show a select list in Global Config which would change the set of parameters appearing in the tabs. The selection of parameters would changes the site's personality.

Regarding different sets of features to handle different admin audience requirements, the superadmin could have the ability to turn added features on and off. It could ship with common default setting that are targeted at newbie users. Lower level Admins would never see advanced controls for defining a sites personality (feature set). One possible approach would be to provide a select list in the Mambo Installer that allowed users to choose from a selection of site types (community, document management, e-commerce, corporate, intranet, etc.). The installer would then install a configuration parameter set catered to the users needs.

Based on what I see happening in CVS, Sections and Categories are about to go where the dinosaurs went in favor of modified preorder tree traversal (pure node structure with descending categories and siblings) which is going to add more complexity internally. Concealing the complexity is less of a problem if the user interface terminology does not play up that complexity (completely ignores it) and lets the user use categories intuitively. It would be more like selecting items from a tree in a file manager in this respect. Most users can relate to this and trees in general are very intuitive for a user.

When you build a software application, you usually design it for one or more target audiences. With Mambo, it has the ability to wear a lot of different hats and be a lot of different things to many different groups of users. It could be a very simple site or a very complex site given its current element extensibility qualities.

In the end, I think you will find that most admins have different needs based on their own personal perspectives about site operation and their target user audiences. Joe Blow needs this set of features to cater to this user audience and Julie Smithe needs this set of features to cater to another audience.

eyezberg

December 13th, 2004, 01:26

...Regarding different sets of features to handle different admin audience requirements, the superadmin could have the ability to turn added features on and off. It could ship with common default setting that are targeted at newbie users. Lower level Admins would never see advanced controls for defining a sites personality (feature set). One possible approach would be to provide a select list in the Mambo Installer that allowed users to choose from a selection of site types (community, document management, e-commerce, corporate, intranet, etc.). The installer would then install a configuration parameter set catered to the users needs. The select list is how the Xaraya install works, you may have tested that..?
The problem then is: I am new, just want to get my personal pages up there on the Internet, were recommended mambo "because it's so easy", then I start the install process and it asks my if I want a portal, community etc.. website and I have no idea what these are, where the differences lie etc etc.. And if I choose one and later want to change, will I be able to etc => lots of additional docs needed to guide users right from the start (maybe even example screens to show the different (possible) looks depending on their choice etc..) Room for lots of additions if considered necessary/usefull..
Also the question about Mambo's target audience(s) (see below).

...When you build a software application, you usually design it for one or more target audiences. With Mambo, it has the ability to wear a lot of different hats and be a lot of different things to many different groups of users. It could be a very simple site or a very complex site given its current element extensibility qualities. That's why I asked for the general idea behind Mambo, and what plans are for future dev.. => http://forum.mamboserver.com/showthread.php?t=24300
I believe having a clear idea as to what Mambo CORE is supposed to be, and who is supposed to be the target audience(s) of post-v5 versions would go a long way in defining what features to add/developp/remove/include...

...In the end, I think you will find that most admins have different needs based on their own personal perspectives about site operation and their target user audiences. Joe Blow needs this set of features to cater to this user audience and Julie Smithe needs this set of features to cater to another audience. Yes, and that's also just one ADMIN (who I guess is the superadmin?), when there can be so many other people accessing (parts of) the backend for specific tasks.
I really think the backend should adapt to the admin user's access level in the same way the frontend does via admin templates which hide all non-accessible content (menu(item)s) for one part.
Another part is then still providing an option to change the layout, because for new users, all the menus might not be needed straight away.

In fact, on first access to the backend, I can imagine a pop-up, same as when you start using new software kinda "tip of the day" thing:

"allow us to guide you through the most common site configuration tasks to get you started. Please check this box to not display this again. It will still be accessible later from the "Wizards>Initial Configurations" menu. Keeping this demo window open allows you to perform the actions shown on your live site right now. Click next to start."

And then you get: (order to be refined..)
*screen "to configure frontpage" (hidden in manu params in 451...!)
*screen "to add/remove/edit sections & cats"; or folders (new in v5)
*screen "to add/remove menu/items" (once that works..)
*walkthrough of "global config" with detailed help
*...
*last item: "congrats, your site is configured to