Tools

bergie said

bergie  

Wireframing the Midgard2 CMS UI

26 comments

bergie posted to #midgard 15.01.2010 (en)

26 comments

Bottom

bergie  

Basic idea is to get rid of current toolbars approach, but expose a lot more functionality on the pages via some simple buttons:

  • Switch between editing and browsing mode. In editing mode we introspect all items on page and provide actions (edit, delete, ...) for them
  • Activity stream where you can see all changes in current workspace and parent workspaces (a bit similar to BaseCamp Dashboard). This is also where you move content to another workspace to publish it
  • View inspector which shows you all code, configs, and templates used on the page together with their documentation. Also allows overriding them
  • Account to allow changing account settings and login methods. This is where you connect your Midgard account with third-party services

bergie commented on posted to #midgard 15.01.2010 (en)

bergie  

When you go to editing mode we create you a new workspace under the current one. All edits you do in the session are made in this private workspace and you can merge them to parent workspace either fully or selectively.

Because all edits happen in a private space all editing tools will autosave things to ensure no content is lost in case of browser crashes or network outages. This should probably use HTML5 local storage as a fallback.

When merging changes we ask user to provide some change comment (compare this to commit messages) that will be used in the activity stream.

bergie commented on posted to #midgard 15.01.2010 (en)

bergie  

In editing mode we need to be aware of current client. With WIMP devices we can display the actions available to a content item on hover. With touchscreen devices the icons must be bigger and always present as there is no hover.

We need to amend current Midgard MVC actions spec to support also the concept of "actions to lists" so a list of objects (say, navigation) can be rearranged and added to using the actions.

Editing tools should be designed to be as compact as possible so you can see all manageable data on screen. When you focus/activate some control (say, article content), the editing interface for that field maximizes to provide a large working area (a WYSIWYG editor should take at least 80% of screen).

bergie commented on posted to #midgard 15.01.2010 (en)

bergie  

Some principles for the new UI:

  • Direct access: all content manipulation must be possible directly on the site. Not only editing as in the old MidCOM AJAX editor but also adding and reorganizing content
  • Learnability: the workings and structure of the system must be discoverable on-site. This includes everything from documentation to configs, code and templates, all not only browsable but also editable. OLPC's low floor no ceiling approach is a good guideline here
  • Connectivity: no website should be an island. A Midgard site should effortlessly connect with key social web services both by pushing and retrieving information on them. This could include an OCS-style shared knowledge base

bergie commented on posted to #midgard 15.01.2010 (en)

Jemiweb  

You have put a lot of thought into this. I'd like to contribute to this when the time is right.

Jemiweb commented on posted to #midgard 15.01.2010 (en)

bergie  

@Jemiweb I'd like to sit down over a beer or two and draw some wireframes. Maybe @adrenalin would also be interested to join?

bergie commented on posted to #midgard 15.01.2010 (en)

bergie  

For rich content editing we need a tool that completely integrates with the rest of the system, both functionally and visually, and doesn't just look like Word 97 slapped into a web form. This probably means building a custom editor, maybe using WYMeditor as the basis.

The editor should not only provide normal document formatting, but also should provide tools for including semantic information inside a page. For example, Insert person in addition to Insert image.

These insertion tools should use a rich dialog that provides both searching, browsing and adding new items of that particular type. In some cases like images you should be able to decide what variant of image you're including (thumbnail, greyscale version, original). The same dialog can then also be used in situations where we now use the chooser

bergie commented on posted to #midgard 15.01.2010 (en)

bergie  

Workspaces are used for three different scenarios:

  • Workflow - there could be a "staging" workspace under "live" workspace from where things are moved to the live workspace when ready
  • Multilingual publishing - Translated version of a website can be a workspace under the language it is translated from
  • Editing - Private workspaces can be used for "sandboxing" editing sessions

bergie commented on posted to #midgard 15.01.2010 (en)

bergie  

Configurable trigger system, a bit like generic version of OpenPSA smart campaigns editor can be used for things like:

  • Automatically moving matching content between workspaces
  • Firing notifications to users
  • Firing webhooks
  • Sending DBus signals
  • Initiating gearman jobs
Zendesk has a pretty good example of such system where you can for instance automatically publish Qaikus when particular types of tickets are entered into the system.

bergie commented on posted to #midgard 15.01.2010 (en)

bergie  

Midgard Runtime and the MVC installer need to provide an environment where you can copy a website (or a workspace) to your own computer for development or offline content editing

bergie commented on posted to #midgard 15.01.2010 (en)

bergie  

Semantics should be utilized by the system. This means publishing pages with content being machine-readable through RDFa (or Microdata, should tha prove to be popular). The semantics used should come from MdgSchema ontologies.

We also need to understand externally linked content. If you link to an event somewhere the system should be able to notify you if that event is rescheduled or cancelled.

In addition to semantics rising from MgdSchema ontologies and their relations we could use semantic lifting to understand meaning of rich text content. HTML entered via editors should in general be treated as structured data to be managed, not just blobs of "content"

bergie commented on posted to #midgard 15.01.2010 (en)

adrenalin  

@bergie: Beer sounds always good. I'm in if the time suits me.

adrenalin commented on posted to #midgard 15.01.2010 (en)

Jemiweb  

A planning session would be nice. The coming weeks are quite tough, but this is a welcome brake to many projects :) This weekend I'm in Hki, next weekend in Hanko and after that in the Dominican Republic :)

I guess tomorrow is too soon @bergie @adrenalin ?

Jemiweb commented on posted to #midgard 15.01.2010 (en)

bergie  

Planning session in Dominican Republic sounds good ;-) This weekend is already sold, but if we can steal some evening during a week?

bergie commented on posted to #midgard Helsinki, Finland 16.01.2010 (en)

Jemiweb  

This could be useful: http://mozillalabs.com/blog/2010/01/t...

Sure it's just for Firefox/mozilla, but it could be really sweet and powerful? I'm aware that we have to make everything cross browser and accessible, but still this could add the user experience to another level.

Jemiweb commented on posted to #midgard 19.01.2010 (en)

bergie  

@Jemiweb I've thought about it a bit, but seems XUL wouldn't give us many advantages over a more cross-browser HTML5 approach. A Firefox add-on might however be useful for recognizing Midgard sites and performing things like autologin and faster access to some functionalities.

bergie commented on posted to #midgard 19.01.2010 (en)

Jemiweb  

@bergie jetpack is not XUL it is a Mozilla Labs project that enables anyone who knows HTML, CSS, and JavaScript to create powerful Firefox add-ons.

So basically with slight adjustments, we might get 2 flies with 1 hit? Probably not, but let's be optimistic :)

Jemiweb commented on posted to #midgard 20.01.2010 (en)

bergie  

We'll have the first UI sketching session with @adrenalin on Jan 28th. Anybody else interested in participating? I believe this will be a chance to build a completely new kind of CMS.

bergie commented on posted to #midgard Kaisaniemenkatu 3, Helsinki, Finland 21.01.2010 (en)

bergie  

Another question: should the CMS be called something else than Midgard to avoid confusion ?

bergie commented on posted to #midgard 26.01.2010 (en)

Jemiweb  

Any new sessions coming in the near future? Ping @bergie @adrenalin

Jemiweb commented on posted to #midgard 10.02.2010 (en)

bergie  

@Jemiweb yep, there is a session scheduled for tomorrow

bergie commented on posted to #midgard 10.02.2010 (en)

Jemiweb  

Damn, my plane lands on friday morning. I guess I have a lot to catch up and hopefully something to add to the plans...

Jemiweb commented on posted to #midgard 10.02.2010 (en)

TomiS  

@bergie About naming: I think Midgard CMS fits in quite nicely with Midgard MVC and Midgard Core (and others). All of them belong to same software family but operate on very different architectural level. Furthermore, due to the fact that CMS is written on Midgard MVC, the full name of it should probably be something like 'Midgard CMS for Midgard MVC' with component name 'midgardmvc_cms' but of course in practice 'Midgard CMS' would be the name to be used in every-day conversations :-)

TomiS commented on posted to #midgard 07.07.2010 (en)

bergie  

@TomiS yep, but we also have to be careful about naming. Now when people hear about Midgard they only see the CMS, not the three layers we actually have (content repository, web development framework, CMS)

bergie commented on posted to #midgard Tampere 07.07.2010 (en)

bergie  

Some notes about the different views we'll need:

First login:

  • User is redirected to profile page
Profile page:
  • Welcome to Midgard!
  • User information box, details editable via Aloha (or via a traditional form)
  • Link your account to web services:
    • Facebook Connect
    • GitHub
    • Flickr
    • - ...
  • Now you can start by:
    • Editing your new Midgard site (link to front page in edit mode)
    • Developing a Midgard web application (link to manage view page and to developer guide)
    • - Installing an existing Midgard application or website (link to import tool)
Regular Midgard page (including the front page):
  • The page is shown as-is
  • On left-hand side we have a floating set of small (but finger-friendly) buttons:
    • Edit mode (loads Aloha to the page)
    • Activities (goes to activity stream page)
    • Manage View (goes to manage view page)
    • - Profile (goes to profile page)
Note: we should have a sensible default template shipped with Midgard. Something that looks nice, can be customized via CSS and has all the basics like navigation

Activities page:
  • List of latest activities on Workspaces available to you, sorted by workspace (a bit like BaseCamp dashboard)
Manage views page:
  • This node is handled by "midgardmvc_core"
  • List all routes available for the page
    • Routes are editable (link to manage view)
    • - Add route
Manage view:
  • Split view: an accordion on left, on right the actual page
  • URL parameters can be edited via input fields
  • In the accordion:
    • Configuration
    • Config editor
    • Controller
    • PHP editor (readonly for filesystem controllers)
    • Data returned by controller
    • Data dump for display
    • Template
    • - PHP editor
  • All editors autosubmit their changes after validation, and refresh the page displayed
Developer guide page:
  • Tabs on top: Developer guide, Reference
  • Developer guide text

bergie commented on posted to #midgard Tampere 07.07.2010 (en)

Jemiweb  

Was Bespin dumped as I understood it would be considered as an editor for the more advanced stuff?

Jemiweb commented on posted to #midgard 08.07.2010 (en)

Login or register to leave a comment

Publicity
These messages are public and can be seen by anyone.