-
What UI is up to archive
last modified December 18, 2007 by missmoun
<< back to Design Tracker or see the
IxD archive
September 10th, 2007
Ajax/UI specifications.
Objective
Come up with the best possible solution for some of the standard Ajax/Javascript driven UI features.
Features and behaviors to deal with
- live edits of title
- live edits of texts (single and multiple paragraphs)
- BackPack (re: the hover tabs)
- live edits of forms
- live edits of single elements inside forms/table: drop down menus
- TeamSnap (via Vitamin)
- live error checking on forms
- expanding and collapsing of content in tables and forms
- loading & saving data live, user feedback
Comparative analysis
List relevant examples from other sites.
Sometime before august 2007
| Page
|
Mockup | Status | Now (who) | Next (who) | Notes |
|---|---|---|---|---|---|
| Project Portal (on Flow) | #2 | HTML making | Rollie |
|
|
| Your Projects (on Flow) | #14 | HTML making | Nick |
|
|
| Project Search Results | #4 | HTML making | Rollie |
|
|
First, the overarching plan: After the Task Tracker and Listen deployment iterations have drawn to a close, we will have an iteration dedicated to rolling out the new UI. Happily, this will coincide with Rob, Whit, and Ian being in town, so it should be an exciting and productive couple weeks. In the meantime, I have been working with Mouna, Rollie, and Nick Grossman to get the infrastructure in place for them to mock up our new templates and stitch them all together.
Objectives
After the work Rollie and I did fighting with the existing UI infrastructure (macros, slots, schemas, etc.), it became apparent that if we wanted to make the best use of our designers (Mouna, Rollie, Nick), that is, fit their work into a non-blocking development process with the work of our programmers, we would have to come up with a cleaner infrastructure for developing and generating UI. To that end, we decided to scrap the inherited template infrastructure entirely and write a whole new one, composed entirely of zope3 views. This has the added benefit that each zope3 view is independently viewable from outside of zope, so if an external application (e.g. Task Tracker or transcluder) needs only a particular part of the OpenPlans UI, it can refer to it with something like "http://openplans.org/@@someview" and get just what it wants. Task Tracker is already doing this with the topnav, to great effect.
Setup and Organization
The new UI infrastructure lives in an opencore branch I cut last week called "nui". However, all of the activity in this branch has occurred in the opencore/nui directory, so merging it back to the trunk should be cake. In fact, right now I have just the opencore/nui directory checked out of my branch running against an up-to-date opencore trunk, and everything works smoothly. If you would like to replicate this setup, cd into the src/opencore/opencore directory of your instance and run "svn co https://svn.openplans.org/svn/opencore/branches/nui/opencore/nui". Then just uncomment out the slug in src/opencore/opencore/configuration/configure.zcml for opencore.nui and you'll be in business.
The first thing you'll notice in the opencore/nui directory is a bunch of .pt files, a couple .py files, and a good ol' configure.zcml. There are also some resource subdirectories (e.g. img, css, javascripts). All the configure.zcml does is register those directories as "resourceDirectory"s and then register each of the .pt files as zope3 views, all associated with the OpencoreView class. The purpose of this class is to provide all the information a template could want in an obvious place and in a template-convenient format. Since all the .pt files are bound to OpencoreView, they can access it simply with the "view" tal variable.
So how does this lead to a cleaner and swifter UI development process? Well, when Nick or Rollie are tackling a new template, all they have to do is write a new .pt file in this directory and add a <browser:page> for it in the configure.zcml[1]. Any dynamic data they need to get from the view can be substituted with dummy data in the template. Nick is actually getting comfortable enough with this system that I wouldn't be surprised to see him move the dummy data into a view method and call that from the template. That just leaves making the view return live data for the programmers, and we have a nice, parallel workflow. As proof, the yourprojects mockup was completed on Friday afternoon with virtually no developer intervention.
I should go into greater depth regarding the .pt files. The first I'd like to discuss is magic.pt. This is the global template in which all content is inserted, and as such, it is the only template in the whole directory with an <html> tag. Inside the <head> is included all the javascript and css any template might need (this is okay because ultimately it will all get compressed together anyway for caching/performance reasons), and in the body's main div there are three divs:
- one for the topnav: <div tal:replace="structure here/@@oc-topnav" />
- one for the footer: <div tal:replace="structure here/@@oc-footer" />
- and one in between, where the actual content is injected.
How the content is injected
Right now, magic.pt checks its query string for the argument "oc-content". If present, it includes the view named thereby. So if you go to http://nui.flow.openplans.org/projects/jabtestproj/@@magic?oc-content=oc-project-view, it is as if the div in between the topnav and the footer in magic.pt had been <div tal:replace="structure here/@@oc-project-view" />. If oc-content is not present in the query string, magic.pt asks the view to which it is bound if it can infer the content template based on its context. So, you can go to just http://nui.flow.openplans.org/projects/jabtestproj/@@magic and it will still work.
This doesn't feel like the right way to do this. It seems you should not have to resort to query strings or magical context inference to get your UI stitched together properly. On the other hand, it has provided an easy way for Nick and Rollie to stitch templates together thus far while being super D.R.Y., so if only for the short term, it has been adding value. Plus, this system has the sweet side effect that all existing OpenPlans URLs render exactly the same as on the live site, but if you just add "/@@magic" to the end of the URL, you will be instantly transported into the snazzy alternate dimension of the new UI. Once we are ready to go live with the new UI, it should be a simple matter to make @@magic the default view on all content. Until then, being able to have the old and the new coexist peacefully is pretty awesome.
Deployment
As you may have gathered, I have deployed a nui-equipped OpenPlans instance at http://nui.flow.openplans.org. Right now, the best way to get into the alternate nui dimension is via the jabtestproj link. I will link to all the new templates from there. If you click around on some of the other links, you'll find they point to as-yet-unimplemented new templates. There shouldn't be any broken links, however.
Nui-related tickets are still available at http://trac.openplans.org/openplans/report/16. Note that their component is still listed as "naked" (a vestige from an earlier incarnation). Please continue to use "naked" for new nui tickets for the time being. I'll let you know if this switches over.
Links
nui mockups in progress
http://openplans.org/projects/opencore/main-interfaces
-- Josh
[1]If we could do something Grok-like here ("convention over configuration") to eliminate even this step, it would be super cool. If you look at all the <browser:page>s in the configure.zcml, you'll see there's nothing incredibly interesting going on here.
if it would streamline workflow, we could add a directive to automate the registration [dwm]