Midgard
Open Source Content Management Framework
Midgard Project > Discussion > Developer forum > MidCOM 2.5 UI tuning

MidCOM 2.5 UI tuning

  1. Henri Bergius

    MidCOM 2.5 UI tuning

    Thu January 01 1970 00:00:00 UTC

    Hi!

    I've asked a team from our office: Arttu, Oskari and Joonas to work together to produce a tuned default UI setup for MidCOM 2.5.x. This would include:

    • Datamanager 2 CSS
    • MidCOM toolbars CSS
    • TinyMCE configuration
    • and possibly some CSS/UI work for the image pop-up

    If we get nice implementations for these three, the user experience with MidCOM 2.5 will be much better. The on-site admin metaphor is quite nice, but the way it looks like by default could be improved.

    I'm looking forward to the results. If anybody has ideas or wants to participate, would be great to hear about it here :-)

    BTW, the default TinyMCE setup WordPress 2.0 uses could be a good starting point: http://blog.tinyau.net/images/wordpress20-wysiwyg-interface.png

    /Bergie

    •  Reply
  2. Tarjei Huse

    re: MidCOM 2.5 UI tuning

    Thu January 01 1970 00:00:00 UTC

    Howdy good folks

    This sounds good. I would like to come with a few suggestions and tips. I've done some minor css tweaks for the midcom toolbars while working on integrating A2 topic editing into them.

    The changes has been placed i static/midcom.admin.core/toolbars.css. I haven't committed yet as I wanted to get Torbens heads up on the name, but I suggest we keep one css file in midcom.admin.core that provides the css needed to display the basic interface onsite.

    The way I've done it is that this (that is the menus) is displayed floating at the top of the screen. Thus they will not be pushed down by longer UIs.

    Wrt to the image pop-up, I welcome any tuning and hacking that is done. I'll commit the version I got now so that it may be tested (it uses tha schema of the article instead of just showing all the images).

    regards, Tarjei

    •  Reply
  3. Tarjei Huse

    re: MidCOM 2.5 UI tuning

    Thu January 01 1970 00:00:00 UTC

    Hi, one more thing. It would be very nice if you guys came up with a set of accesskeys that should be used here and there.

    •  Reply
  4. Henri Bergius

    re: MidCOM 2.5 UI tuning

    Thu January 01 1970 00:00:00 UTC

    I wrote down some ideas yesterday:

    Floating MidCOM toolbar

    Arttu told me about his ideas for the new unified MidCOM toolbar. The basic idea was good, and I though it might be beneficial to develop it further.

    The toolbar

    The Midgard toolbar would be a rectangular box with rounded corners floating fixed in the browser viewport. By default the box would appear in top right corner of the screen.

    User could move it around, and it would communicate the position moved to to the server via AJAX. The position would be stored in user's parameters and remembered across sessions and screens.

    The toolbar would contain from one to four menus and a logo. The logo would be on the left.

    The floating toolbar would have several advantages over the current situation:

    1. It would work with any layout
    2. It would be always available regardless of where user is scrolling in a long document
    3. It would look cool and polished, which the current on-site toolbars don't necessarily do
    4. It would clarify the use of the different toolbars

    Midgard logo, About page

    By default the logo shown in the toolbar would be the Midgard logo (streamlined to fit here), but it should be changeable on server-wide basis using MidCOM configuration parameters to a hosting provider's logo or something like that.

    Clicking the Midgard logo would pop up a "About Midgard" window that would contain some basic information about the Midgard setup:

    • Short "Midgard is an Open Source Content Management Toolkit" explanation with link to project site
    • Installed Midgard, PHP and MidCOM versions
    • Current sitegroup name
    • Maybe a scrolling credits list autogenerated from Midgard Who's Who?
    • Maybe notification if there is newer MidCOM version available?

    The info window could be a regular browser pop-up, or a lightbox-style DIV. This has to be seen when we start implementing it. Probably the practical implementation for this would be a /midcom-exec-midcom handler.

    Menus

    The menus would only be displayed if they contain some items enabled for the current user. The different menus I see are:

    • "View" menu containing the view toolbar
      • I would like to label this menu based on whatever the current view is. So instead of "View" or "Page" it would be labeled "Article" or "Forum"
      • This way the clicking paths would be quite logical. "Article -> Edit" or "Forum -> Create thread"
      • Metadata editor (once we port that to 2.5) would be here too, "Edit metadata"
    • "Folder" menu containing the node toolbar
    • "Publish" menu that would be visible in the following situations:
      • Site is using staging/live (new MidCOM config option needed?)
      • Site is using approval checks
      • In addition to the "Approve", "Schedule" buttons the menu should also show a clear indicator in text (unlike the current icon solution) saying "This article will be published at 09:00 tomorrow"
    • "Help" which would actually be direct link to a midcom.admin.help contextual help document
      • The "Help" button should be available only if there is a help document available for the view
      • Maybe the document should also open in popup, or at least another browser window

    Obviously the View and Folder menus are the most urgent ones, but I would like to keep the other menus in mind as well.

    The menus could either open on a click, or on hover. This needs to be experimented with.

    Bells and whistles

    The Lightbox javascript library is doing some trick to "darken" everything outside the opened picture area. The same effect could possibly be used outside the datamanager editor when editing something to highlight what parts of the screen are editable.

    We could use Scriptaculous effects for making the toolbar move very smoothly, and the menus expand in animated fashion. Has to be investigated.

    /Bergie

    •  Reply
  5. Arttu Manninen

    re: MidCOM 2.5 UI tuning

    Thu January 01 1970 00:00:00 UTC

    We were having a small discussion of the topic with Bergius Jr. (aka Joonas Bergius) and Oskari Kokko.

    Some of the keypoints we were talking about were

    • toolbars should be configurable and configuration inheritable (last is the strongest)
      • server
      • sitegroup
      • (site)
      • user

    WYSIWYG-editors

    This goes especially to TinyMCE and htmlArea. I would suggest that we will make the user experience nice and give a GUI to twiddle the settings for the user.

    I also suggest that we can determine the possibilities with ACL eg. in the following way (this one is for administrators)

    Bold    (x) default   ( ) yes   ( ) no   [ ] power user setting
Italics ( ) default   ( ) yes   (x) no   [x] power user setting

    This would be interpret that italics would be off for a certain user and only power user can change this setting. Of course the end user won't even see those marked with power user level nor to set it on.

    Toolbars

    We would place toolbars eg. on the right side of the screen with fixed positioning as Bergie was also mentioning. They also could (or should) be distracting as little as possible, so I would be hiding them as default and showing them on hover (or onMouseOver in case of IE).

    I was playing a bit around and made a small example:

    • http://www.kaktus.cc/?toolbar

    This example has been tested with Firefox, Camino and Safari. Due to time limit I didn't even bother to try it on Internet Explorer. There shouldn't be anything preventing it from working (besides position: fixed and hover, but both of these have simple fixes anyway).

    This uses script.aculo.us (I simply hate writing these dotted things, the same goes to del.icio.us) JavaScript libraries. At the moment the toolbar is positioned with CSS, but I think that it should be less error prone to non-JavaScript browsers and have JavaScript change the CSS on load.

    These settings should also be memorized either by JavaScript into cookies (this would still make MidCOM caching possible, even though with non-MidCOM template pages performance shouldn't be a problem) or by Ajax to tie the position to person preferences.

    Local cookies might be the best option because of different screen sizes. It would prevent the toolbar from being hidden away if using a screen of different size.

    Datamanager2 itself

    We were pondering on access keys. I think that 'Submit' should have an access key (eg. Alt-S as just an example). This could also be configured by

    • component
    • schema

    Even though this wouldn't be a part of progress now, I would like to reserve keywords for this in schema definitions already.

    Some widgets also should be using less space. Eg. datatype image should give full access over the display size, description text and such, but this shouldn't be visible all the time to put on load for image editing.

    •  Reply
  6. Henri Bergius

    re: MidCOM 2.5 UI tuning

    Thu January 01 1970 00:00:00 UTC

    Arttu told me about his ideas for the new unified MidCOM toolbar. The basic idea was good, and I though it might be beneficial to develop it further.

    Here's the first version of the toolbar. We will IE-test this and then roll it into MidCOM proper:

    http://www.kaktus.cc/weblog/midcom-toolbar.html

    /Henri

    •  Reply

Discussion

Copyright © 1999-2010 The Midgard Project. Open Content
Designed by Nemein, hosted by Anykey