DC2009:The convergence of architecture and content

Description

A long time ago, before Wikipedia and Facebook and other innovative online platforms, the line between software and the data managed by software was fairly clear. No more. But in so many technology projects these days, content is architecture and vice versa. This session will reflect on the convergence, and consider best practices for designing to meet long-term needs and requirements.

Session Notes

Robert - changemakers - merging content and architecture

Introductions

Changemakers looking at a redesign had developer they liked needed design help hired adapted path from SFO for design good process - integrated project, developers and designers together, Drupal came to a point at end of design phase, became clear that there was a gap between the folks that would provide the content and their knowledge of the site and where to put it, user interface vs content. e.g. right hand navigation - 'do i have to write that' also were in 4 languages - even more complicated robert comes from arch and design background - have well established processes web world - no standard convention for symbols, how it all works together became clear that it would not be possible to have the content in time for launch without a content map.

Took wireframes pre-build, and tagged each piece of content with callouts (e.g. callouts for top nav bar - home, about, etc) had a unique identifier (alpha numberic ABC), brief description, author (who is responsible for producing it), goal / purpose built a set of excel tables w/ all the info in it plus more detail.

Can print out screenshots of site, mark it up, and push it to the right people. gives people an idea for where they have to provide content.

Long excel list...

CONTENT ENG SP FR TYPE HOME STATIC

IMAGES.

Adam - likes to get writing of content started as soon as possible. often starts before design is complete, but structure has been decided.

Was very hard for people to understand what it meant. Lots of user generated content. Being able to visually articulate where things will go and giving them context was very helpful.

Can go after people to author stories. hard for folks to imagine something entirely new without a picture.

If content is late - what does it delay? doesn't stop development or design, but can be helpful. When you actually go to write it - there will be changes. But cant launch till content is complete...

1st focus on the primary content necessary for launch. Start as soon as possible. Herding cats. One reason it can be hard is that people cant visualize it. Changemakers had an almost entirely distributed team, people all over. Had lots of stories, when we did a tone analysis, decided they needed to redo them.

People need to see it to understand. WORD COUNTS - very helpful. Helpful in managing up. CMS can reinforce these limits. Visualization is very helpful for content creators - print out screenshots (by page type / template, or actual - whatever you can do)

UGC site (user generated content) vs "brochure site" UGC - need to be further along in dev process before staring content development. Brochure - can start earlier

Adam - start developing content as soon as you have your architecture set (set enough...) The content that is not in sidebars can be done without visualization, but the sidebar content may need to wait for visualization. Depends on team that is working on content. Journalists have hard time w/ fluid process.

One challenge - put out blueprint winter 2008. Translation work went off blueprint. Changes happened. How do you catch the translation work up to the changes. Keeping finger on pulse to know when to notify translators. Moving away from translating content. Suggestion - move away from it.

Changemakers runs competitions for social change - sponsors may want multiple languages, all UI and content need to be in all 4 languages.

Boundaries of user experience on web is largely language. so...UX stops where language stops. translating content into other languages - even by good translators, its bottlenecking based on English version. instead, create assignment in the native language - do it de novo in that language, don't translate it.

Orig authored content vs translated... redesign - will port content over.

Selecting designers and developers - if they are a bad fit for the team, watch out. doesn't matter how hot / good they are. need someone who will work well with the team. Proprietary CMS locks you into long term financial commitments. Tool should be determined based on needs.

Callouts would be grouped by team - (tech / marketing / journalists). 1 guy was basically managing all content. created gantt chart for content delivery. keeping style consistent - style guide? had a person who monitored for that, and sent it back to author if needed.

Did people enter content right into Drupal? Progressively opened up pieces of the new CMS as soon as possible to the guy managing content. ended up having to move a lot of content in CMS himself. What would be the best approach? would be best if authors could add their own content. However, Drupal is not the most user friendly back-end. user friendly enough But people are somewhat unsure. depends on tech skills of content people.

Adam - once site def is done, will put together what needs to happen, does basic training on adding content. depends also on ongoing process - if same people will be adding more content, then worthwhile, vs if they are just one-time (then do it yourself).

Scale and complexity of site itself is impt. changemakers is a very intense site. lots of interaction. lots of functionality. CMS is quite complex. 75,000 user profiles associated with changemakers. 3,000 entries (UGC). Navigation top level pages. Spreading content throughout site, leaning on architecture to do that. bid to launch took 1.5 years.

Changemakers was a print mag - went online - have competitions - went on Drupal - realized it was time to make a jump. watch out for old appendages that need to be dropped. e.g. - if your site has always had a section called "programs". your people say that will move over. should it? is that vertical something we need? check to see if anybody uses that section. people will want things that are completely irrational. 'manifesting that content elsewhere' design of everyday objects - good book on design. 'archived section' - aka the graveyard - another good solution.

Keep design space and project management space separate in conversations. keep meetings separate. impt if you are managing up. technology is easy, people are hard. if people are joining for features that they saw on another site - ask about the intent and the need behind it. what is it that you need? can the need be met in another fashion? product integrity...

Metrics can work to modify behavior, but hard.

Other lessons - from adapted path - 'lets fail small' - when you hit the rocks - if there is a problem, identify it, fail small, and get past it. had that when it came to look and feel. fail small now, vs. big later. makes them feel more comfortable with things not being right, keeps things moving.

Always double your developer time. it just takes longer. perspective from developer side is different from user side. TEST TEST TEST. if it doesn't make sense to you it wont make sense to a user. Make sure you have a demo / dev site to test things on. it costs money - but that's better than going public and live and having users question.

Don't let developers push you around. make them show progress. listen to them. everything is a draft. get things done. perfection is not possible, continual experiment.

TESTING - try to imitate the path that a user would take, as a non-admin acct. do it like a user would do it. anytime you feel lost / wondering, take note. takes 2 hours sometimes to write a good ticket. be very precise. I expected to see xxx, I saw yyy, screenshots, etc.