Below is a list of names and email addresses of the people that form this group right now. Most of you have shown me some piece of work or told me about your history with this type of work. Based on this I decided to declare Pauric O'Callaghan the group leader for now and Alan James Salmoni will be the supervisor with HCI issues. If you as a group decide to form a different structure, please do as you see fit.

As already said above, it is up to you how yu organize your work - I hope this is a good approach.

• Pauric O'Callaghan I'm the head usability engineer for 3Com. A major part of my job is working with engineers, taking their rudemantary designs and polishing them with my usability experience.
• Alan James Salmoni Is what I would call an expert in HCI (Human Computer Interaction)
• k1 Is a former editor of several international standards on software ergonomics & usability, have a degree in the subject and have been studying and working in the field for 20 years.
• Maria Black My focus is on usability, I am NOT a programmer - however, that sounds like what you're looking for. Currently I'm doing some contract Web design work, so my familiarity with HTML is probably adequate for doing design mockups
• Jenaro Centeno Gomez I have knowledge about HTML, DHTML and now I am working with the macromedia suite.
• Shabeer Ali Muhammad I am basically a web designer seeking to test out my new 'design philosophy' - The design should supplement the content and not overwhelm it. It should be simple, intutive and visually appealing.
• Allen Warren I am currently the webmaster for the Atol project here at SourceForge and I am also helping to design the graphics for that application.
• Andrew Van Raalte I know HTML, an intermediate place to PHP, and I am currently always expanding my GFX skillz.
• Hans Taeubler I am interested in doing some UI-redesign in princible. I should mention, that I have already a lot of experience in designing and developing workflow-/document management software application (as well as groupware applications).
• Aldo
• Bryan Mark Is familiar with PHP, HTML, DHTML, JavaScript, Photoshop, ... and has already updated the webmail interface so he is familiar with the module-based code.

I have created a mailing list for this group, go to this page to subscribe.

Some of you pointed out the design was already nice, and some of our users told us the same. Nonetheless it is a bit outdated in technical aspects and definitely needs more consistency.

So your task would be to come up with a streamlined design (based on the existing one to make current users happy) that should be possible to achieve with CSS-only layout techniques. One of the main concerns (for me) is having a defined set of colors and styles for the various elements of the UI, so that it becomes really intuitive.

If needed I would love to be able to assist you with technical issues. One thing that is very important to me is a light interface in terms of network load. So using as much CSS as possible is a must, avoiding graphics (where you can) at the same time a good thing.

I would start by identifying common items and functional areas (menu, content, search function, new/delete/back links, ...) and then define visual and functional attributes of those. But you probably know what you're doing...

This was sent to me by K1. It is a list of things he wrote down during testing more.groupware. It is not (solely) something like this list that should be the result of your work (see above), but such lists surely help us coders to follow your guidelines.

• The move from 0.6.8 to 0.6.9/0.7.0 was in some ways a backward step, since although prettier the dynamic menus make it harder for users (they don't know where to find commands unless the explore every sub-menu) and less efficient (more clicks and mouse movements) to get to the item. Given you don't have many sub-menu items, I would keep the option for users to have a 0.6.8 style text based interface (ie without drop-down menus). Ref feature req 821094. If you persist with the drop-down menus...
• Follow conventions for elipsis & arrows after each appropriate item
• Change the word 'Modules' to something less technical - (would need testing with users. Try words like 'Go to...', 'Tasks', or 'Items...' )
• Avoid inappropriate icons (e.g. the right arrow for the current module)
• If you persist with icons for each main navigation menu, use the same icon as listed in the goto/modules menu as the icon for the mudule-specific menu item
• Avoid submenus where there is only one item (e.g. most of the settings menu) Have the menu for the current module on the extreme left and the Goto/Modules menu either next or on the far left just before help
• Move the log out option to the bottom of the goto/modules menu Make the second menu items for some modules a submenu of the main module-specific menu (e.g. change flags should be under Webmail)
• Calendar manager is I'm afraid incomprehensible - perhaps when a manual is written, all will become clear
• For interfaces like that of the files & forums modules, don't display items that are not permissable with the user's access rights (e.g. Details Copy Edit Delete) or better still grey them out and add alt-tect that explains they don't have rights
• Use a consitent format for item actions (e.g. 'new' in files vs 'new' in Todo)
• Button layout: Don't space them - keep butto groups in the same position, e.g. bottom right of dialogue (based on page turning metaphor)
• On your point about standardising interface components, I agree. I suggest at least:
• a date picker
• a file selector
• file/task/item/list columns
• highlight regime (don't rely on colour), e.g. consisent use of bold typeface (e.g. list of stories in headlines need not be bold)

• Radio/option buttons for new file/dir
• Pre-populate the check boxes by default
• Allow for mutiple uploads (eg coppermine)
• Use a folder tree structure
• Create dir should take you there

• Radio buttons instead of add lists with (quicker)
• Allow multiple selections in tree
• Don't allow apparenet allocation of admin rights to non-admin users if this feature is not supported (which apparently it isn't)

• make input fields the width corresponding to the likely length of the information that you need to enter e.g. rss file (url) field is only 19 characters.
• headlines description is far too big
• indicate which fields are required
• use context specific labels (e.g. 'News category name' in new headlines module form, not just 'name')
• make it clear with context-specific support (e.g. words in brackets after/beneath label or to the right of field or pop-up help with 'help...' after the field)
• allow batch entry - consider using a table that allows user to add/edit information in rows
• Go easy on the use of bold - information entered is more important than the labels on a form

• Be more consistent with how you delineate page/screen sections - some mudules use thick lines, others thin, some space, etc. First think of using just consistent spacing rather than lines to demarcate screen areas and divisions, e.g. files area: from top to bottom there are 15 changes of colour (effectively lines) divdiing only 6-7 types of information.
• All status information should be in the same part of the screen
• Put the dir and sub dir files info on the same line
• Put the filters in the column heading row instead of above
• Align the figures to the left of the owner column properly with the appropriate column (project or catergory)
• Consider not displaying zero values Make the size column display the size of the contents of folders/directories
• Avoid red system/status messages unless something is seriously wrong. In which case hard code, rather than rely on style sheet, to ensure legibility under any circumstances.
• Provide more consistent action feedback - e.g. no indication that a copy operation is succesfully in the files module
• Provide alt-text for smileys say what they mean in the Forum module
• Save button should be preview if preview is turned on