Drupal/Economist Project – Sprint 2 Demo from Leisa on Vimeo.
Today is Demo Day at The Economist, where all the various SCRUM teams will show and tell what they’ve achieved in their latest iteration. I thought I might see if I can get into the habit of pre-recording my demo so I can share it with you here and ask for feedback & advice! So, here we go!
In the past two iterations (this project runs on 1 week iterations) we’ve done a combination of research, design and testing the publishing tools that the editorials staff will use to administer what is known as the ‘Channel Index Pages’ – these are pages that you’d land on if you clicked something in the navigation that said, say, Business & Finance, or Science & Technology, and their job is to pull the most interesting current content to the top so that readers can access it more easily.
These pages are made up of a range of elements, most importantly for this demo are News Packages (consisting of a lead story and related stories/media files) and what is known as the Bloggy Chunk (an editable text area that section editors can freely input their own content, it is still very much a work in progress and is variously used as an aggregator for recent interesting stories that The Economist isn’t covering in depth or to highlight interesting reader comments, it may in the future show content from an RSS feed).
Although working within the SCRUM methodology, I am trying to take a systemwide approach to the design as far as possible, so there has been a whole range of questions that I’ve had to consider that aren’t strictly in the ‘stories’ for our sprint (logging on, activating editing, for example), and similarly, I’ve tried to devise interaction approaches that will be reusable across the other parts of the system that we have yet to design rather than just customising the design approach to this individual problem set.
The design approach shown in this demo is still quite lo-fidelity and ‘broad brushstroke’, it will become much more precise over time, at the moment my priority is to try to work through and communicate the ideas as quickly as possible – giving me more time to explore a range of approaches, and to iterate approaches which has been very valuable.
So, if you have a moment and are so inclined, I’d really love to get your thoughts on the approach we’re taking so far. We’re also about to embark on starting some development work on this – to make sure we can build it in Drupal without too much difficulty – so if anyone has any guidance on how best to approach this, modules we should take a look at, anything else you think we might need to know, I’d love if you could share it here!
Look forward to hearing from you and thanks in advance!
(apologies to anyone who saw the first version of this blogpost with the screwy audio synching)
Your tweet for help got my attention.
I can imagine the foundation we need for this to be possible. We need some ‘seeds’ of introspection and reflection left in the UI. For example, form ID that can edit the content.
With pure whole nodes, that is simple.
With other content pieces, it’s going to be more complex. Views display nodes but not necessarily whole nodes or even single nodes. What form do they use? For each display for each view, we need a form, and we need to stash that form ID in the page somehow. (Javascript settings array probably is easiest.)
I like the contextual blue bar and its dropdowns: modules like admin menu moving into core implies this is the way to go. Admin menu has the advantage that it sits right at the top of the page as an overlay, out of the way: your blue bar would need to work as a block somehow, if you’d want it to still be relevant if/when the Economist page layout ever changes. Styling would also be a bit tricky with overflows, floats etc. but that’s hardly the end of the world.
The moving between editing inline (title, some content) and editing in lightboxes (related links) seemed a bit unintuitive to me: some edit inline, some pop over, and you can’t be sure in advance which will do what.
The big problem – as I’ve seen discussed in the context of d7ux – is that there isn’t guaranteed to be a one-to-one correlation between content on a page to click on and edit, and a CCK field you can hang that content off and save the edits to. Depending on how the Economist themeing has been set up, there may be very little correlation indeed.
One route to go down if you were starting from scratch would be to plan your page layouts to quite strictly use CCK template overrides – content-field.tpl.php and its siblings – and not to put any content rewiring in your node.tpl.php: always just output the $content variable and let CCK take care of the innards. The disadvantage of this is that there are some layouts, that are natural for the reader and favourable for the designer, that cannot simply be rendered as a tree of input fields converting themselves to inline content.
Basically, if you want to turn text X into input field x for inline editing, and do it consistently, then you have to accept that your uneditable page will consist of discrete text X, Y and Z: otherwise you can’t pick them apart to edit x, y and z inline.
Another route, which retrofits rather nicely regardless of how you’ve built your theme, is to move entirely to lightboxing. You adapt the page title inline to have an edit tab by it – much like in your example – and then clicking on this permits editing in a lightbox overlay without navigating away.
We’ve actually worked on a module to do this using D6 theme preprocess hooks, rather confusingly called editinline. There’s some screenshots available, and the source code is on our work repository. It might tie in with some of what you’re trying to do, so let us know if it’s of use.
Hi Leisa, great stuff as ever, and nice to see the extent to which you are pushing what Drupal can and should be capable of supporting.
I’m really interested in the point at which you think that ‘in-page’ editing might transition to ‘in-the-cms’ editing (if at all). I can see some potential for this becoming an issue with say managing published/unpublished/embargoed packages where doing this within fairly constrained screen estate is going to become pretty tricky. I think that is probably about establishing where ‘writing’ finishes, and ‘managing’ starts.
The second thing is more of a design fidelity issue, thinking from the potential mindset of someone from a print background: is there any extent to which editors will have/need the ability to ‘set’ the content and adjust type size and weight to avoid end of line orphans and that sort of thing. Again this could have some implications for the interface and the options required. One of the nice things that I think Textpattern does as a (much simpler) CMS is borrow the language of traditional print – something that may lend itself to this particular project.
Really inspiring work – thanks for sharing it.
A
p.s. please tell me you’re not really following Kirstie Allsop, are you…? ;-)
Very cool video–thanks for sharing. I’m buidling a module for a really similar project (with daily editions and trying to get the user interface as simple as possible) and it is interesting to see how similar we’re thinking about the various challenges. I hadn’t thought about the “library of objects” or the “bloggy chunk” (although I had been considering offering a completely “custom content” space for folks to add as well) and really like the addition of the “edit field in place” feature…
I’ve given the particular challenges of “how to control layout” in different areas quite a bit of thought. Like you, I was thinking originally that the dragged “package” would figure out where it was located and adapt its presentation accordingly (like having some regions set certain CSS Styles for the object when dropped–but it seemed apparent pretty quickly that the CSS would have to be pretty involved and quite complicated).
For a number of reasons–including the user saying: “What happened to my layout”, but primarily because I think I know how to make it work in the backend with my new method–I’ve since gone to a slightly different approach.
My “Packages” are “objects”, and instead of your “hero/Primary, Secondary and Narrow” I had been (and am still) using “Feature, Teaser and headline” (again, ridiculously parallel) because it seems that any presentation of all node-content on a portal-type page would take one of those forms–in general–and anything else could/should be added via blocks or my “custom content object.”
As you mentioned in the video, you weren’t sure whether those 3 types would be sufficient or whether that was the final list–again, I had gone down the same route and decided to start thinking about it in terms of different templates for the different objects. So for example, the Feature object could have a variety of displays–ranging from a rotating js “highlight” story image, to a highlight story image with thumbnail previews of the other highlighted stories, to a more detailed node’s display with related stories (hadn’t though to allow them to choose the particular related ones–but that makes a lot of sense). So your menu changes slightly to have little thumbnails of the various feature, teaser and headline displays that are provided by these templates, and those are the objects that you end up selecting and adding to the page. The other point to add is that these templates would only be created by the site developer/themer so you could make sure that every object (no matter what it was next to) would be both internally and externally consistent (and good). Further, you could enable/disable certain objects’ templates for specific channel pages, users, etc…
Another important aspect of the “multiple template for each type of object” approach is that the template can specify a width (preferably by %). Then I can create instances of a smaller Feature object (say 50% of the available container, with the title followed by a decent sized image centered over the first x-number of characters of the node teaser) and also larger Feature Objects (100% — your “hero” type) at will. By providing basic 100%, 50%, 25%, 66%, 33% type options (maybe even multiple 50% versions of Teasers–one with a thumbnail image and one without that mixes up the text display a bit–depending again on the needs of your site), you give your editors the ability to visualize and realize more custom page layouts–decisions that they can make based on the sort of content that they have in that channel on that day. For example, if on a particular day there isn’t really a great “visual” element to fill that Feature object, you could allow the Editors to simply grab 3-4, 100%, teaser objects and they would stack (visually taking up the same amount of screenspace as the feature 100% might have)–or they could have 6-8, 50%, teaser displays in the same space. Another advantage to this approach, is that you can create “sub-header” type regions by creating an object and giving it a title/label; in this way, Editors aren’t stuck always needing to plug something into an “Environmental News Update” region… and that region doesn’t always have to be in the same place (since some days that story will be more prominent).
Obviously since this is being set dynamically, you can always edit the object and change up the display to fit another template, or even another display type–100% teaser to a 50% feature, etc. I have been working with a simplified admin toolbar at the top of each object–visually they remind the user that the object is still editable, unless you “freeze” that element by switching to a preview mode… helper buttons for deleting the nodes referenced within the object allow the editor to modify the object day-to-day. The whole edition page will have a preview/configuration mode toggle as well, even though essentially you are editing in place anyway, but toggling to “preview mode” will hide all of the admin headers and kill drag-drop functionality–and prevent the Editor from adding or removing additional content.
Originally, the hardest part for me to visualize was the backend logic of how it could actually be accomplished… I was bogged down in a swamp of rows and columns, % containers for each column in each row, etc… kind of like panels, except I wanted it to be easier for them to manipulate. Obviously Panels are awesome, but right now it is a little bit too heavy/involved for my user base, so the idea was to scale that down and let the Editors control layout with drag and drop (only).
If I make the layout objects all float left, and make the whole content area ui-sortable and you can drag and drop these objects in any order you want–the only need is to compliment a 50% object with another one… or two 25%, etc. (or leave yourself some whitespace–but “Editors” should be able to fill the space with a similarly sized object or convert one of the objects to a smaller or bigger size). The key here is that the backend logic is drastically simplified because you would only need 1 multi-valued field to contain all of the “main area” element references (referenced objects–and each of those objects would be connected to a template that determined their width).
Then, because sidebars are so common–and often provide a really nice “structural” (menus, etc) and “familiar” (user’s comfort) element, set a default on whether a sidebar exists on the Edition page (can be overridden in the specific instance of an Edition) and establish object templates/themes as “sidebar capable” (meaning they will be 100% objects designed for a small space). Now you can add objects to the sidebar(s) in the same manner as in the main area (again, with the 1 multi-valued field for object references for each sidebar). And on a specific edition page, you could have 1, 2 or 0 sidebars based on the specific needs of the site (and the permission of the user).
Each layout object, in turn is a container for any number of actual node objects (NOT views or blocks–those would fit into the “custom content area” since they have their own theming, etc), so the templates are to return an array of themed nodes. Oh, and of course each node used in the object should be sortable as well so you can re-order your stories at will.
At this point I have a few “dependencies” including Jquery 1.3x and JqueryUI 1.7x and for drupal modules CCK and one called “Dynosearcho” which is helping me fill the layout objects with nodes (via drag and drop custom code added to it). I was using the AJAX module, but have since written the AJAX calls directly into this module (because I’d rather have as few dependencies as possible). I’ve spent a good bit of time mapping all of this out and am making pretty good progress on the module although it is in the early stages.
Anyway, I don’t know if any of that will help, but that is the basis for the module I’m working on–and I figured since you shared…! ;) Now that I’ve found this project blog I’ll have to bookmark it to keep up on your progress.
Thanks again.