Community wiki

Community wiki
A Style Guide for eGroupWare descrtibes the comon look and feel of eGroupware.

Why do we need a Style Guide for eGroupWare ?

It influences:
  • how easily users get used to eGroupWare,
  • how much they apreciate and accept it,
  • see it as one system and not a bunch of single apps.
    • pobably the best thing to achieve this is designing a programm flow chart. Also helpfull for inside people and developers. Having a flowchart the user can see and diced better if this is what he want and need. (joao)

It is important that all apps and of cause the API adhear to the StyleGuide !!!

The eGroupWare StyleGuide should only differ for very good reason from other well known style guides like KDE or MSWindows, as that's what the users know and expect. The main justification for such a divergence would be that we are building a web application.

''We need a volunteer with good eGroupWare knowledge, not necessarly a developer, to create this document.

I just start adding stuff here, please comment on it !!! -- RalfBecker

  • system-wide
    • Avoid "Mystery Meat Navigation" where possible. Icons, should, in most cases, be accompanied by text name of the program or option, or at the very least in the main tool bar where all the programs are. This makes navigating around eGroupware much less painful. -- erp

  • application header: we have 3 types of application headers atm
    1. bold app-title above a horizontal ruler (sometimes with appended - <sub-function>)
    2. line in table-header background-color with bold app-title
    3. no header at all (eg. Calendar standard view and email for some views)
    • We need to decide for one type for a general app. I would prefer #1, as it allows to have some extra buttons / action icons right alligned above the ruler (eg. (InfoLog)? Add Note/!ToDo/Phonecall Icons)
    • Apps with a very unique look of there standard views like Calendar or Email might be ok without any app-header (#3) for these standard-views, but not for the other dialogs (eg. not the edit/add event in Calendar).
      • don know ... may be it is only a little bit more difficult to get this app ligned up (joao)
  • We created now a standard way to specify the application header, see App-Titles and iDots Sidebox Menu for the details. Which type of app-header to use, depends now on the selected template-set! -- RalfBecker
  • am I too late? I like ability to use a header with extra links/buttons but to maximum the available space, they should be under the application title (not right justified and in line with it). Also, I think extra buttons/links should be arranged in a table format which lends itself to the application title being a bold, shaded background, table header. IMO the most important thing on the page is NOT the app name (I know it, I clicked on it). With my 800x600 laptop display, screen real estate is reserved for valuable information

  • confirmation dialogs: eg. Delete the entry 'Testentry' ?
    • The text about the implications of the decision should be clear to all users
    • the message should contain a title/name of the entry to eg. delete
      • don't take this too hard, but I HATE confirmations and turn them off whenever possible. It takes an extra click and delay for page load. I have figured out what delete means and if I do it by accident and don't hit stop fast enough, I'll live with the consequences
      • that is ok but for the user we need then a clear app manual (joao)
      • Can't we use Javascript confirmation dialogs. Specially for slow connections it very irritating to load a new screen only for the confirmation. Maybe this can be a General Preference Setting? mipmip
      • java may be slow on certain PCs also, what about a simple html-pop-up showing only the relevant info or question? (joao)
    • Buttons (rather than links) should be used
      • - I prefer links over buttons for almost everything (buttons should be used sparingly). If I expect another screen to appear, I can open the link directly into a new window and continue working while waiting for it to load. Consider me a power user if you must but I have better things to do than wait for a page load
      • that also, the average user do not know about this possibilities (unless it is about certain downloads:) so not worth to build it in or explain it. Work applications should be straight and clear, step to step, 1-2-3, the average user will fill up his 8 hours and will no be a poweruser ... so more we build in more the company falls back to standard 'terminal-apps' (joao)
      • links look like web-pages not like applications and in my oppinion eGW should try to look like an application
    • Buttons should be in this order [Yes] [No] (if aplicable: [Cancel])
      • mhhh, I guess no -cancel- yes is the appropriate sequence the rightmost button ever should be the final decision, yes = save (joao)
    • If the Yes/No answer can be missunderstood, make it [Yes - Delete] [No - Cancel]
    • If the app has a app-header the confirmation dialog should have it too.
    • yes, valid for all table data, e-mail to reports, the action buttons shoul be on top of the list as well as on the button to, so the user can use the nearest ones (joao)
  • edit dialogs
    • should have lines in alternating colors and if applicable sub-headers in the table-header color
      • definitely, makes it much easier to read
    • should have left aligned [Save] and [Cancel] buttons and right aligned [Delete] / [Help] buttons - if required
    • don't know, I believe that the most logical sequence is from left to right, right aligned and the final action on the most right, so when I am in a data input form the YES or SAVE button should be in the rightmost position under the last form field. That is as handwriting. You set the point at the end of the last word, no need to go back to left ... (joao)
      • if the table layout (and total table width) is suitable, I prefer buttons centred within the columns. especially if they are close to alignment with the input boxes on the page (allows for an easy workflow/eye follow)

  • add dialogs
    • should have lines in alternating colors and if applicable sub-headers in the table-header color
    • should have left aligned [Add] and [Cancel] buttons and have right aligned [Clear] / [Help] buttons - if required

  • program flow
    • each dialog should return to the calling page / state, eg. if you click on edit in a list or entries, you should end there again
      • An App should give A standard output/error report after every action that is done. There must be a standard message box to show these mipmip
      • Like I wrote in usability, I believe that we have a wast space in the app title header. No need to have an extra line somewhere. This msg can appear n top of the app, right of the app header, another + it is ever visible
    • each dialog should have a cancel button, which returs without saveing to the previous page
    • this cancel button I like to discuss. For me a cancel button is a special button and most of the cancel buttons in most apps do not make any sense. Think about the meaning of the word! When I want a button which brings me b a c k then write return on it. The cancel button should be present (for me) only in situations where I need to confirm the final action: Do you really want to delete this data? Here I need CANCEL and YES. Going deaper even the famous OK is not correct. OK is a confirmation to a question but not the order to save data right. So on a input form may be should be a SAVE button and not a OK button. Let's find out what else and try to use better labels. (joao)
      • each dialog should go to next page anticipated to be desired most often by users. Program flow should be easy to follow and as intuitive as possible. Consider the browser back button my cancel function (I do)

  • preferences and admin/configuration should be made via the standard eGW functions, to
    • have a common look-and-feel
    • use the 3-level user/default/admin approach, to
      • be customizable by the admin (eg. admin can force/switch off certain unwanted prefs)
      • more comfortable to the user
    • use the long helptexts (most users and admin have no idea what most of our configurable options do)
    • see How to hook into Admin and Preferences for more on this

If you have comments or points to add please do so here or mail them to ralfbecker

back to eGroupWare / DeveloperDocs
You are here