Putting Content First - Planning Content Types
•Als PPTX, PDF herunterladen•
3 gefällt mir•569 views
Content Types – they make Drupal awesome and flexible. But do you put content or development first when planning them? If you aren’t planning the content first, you’re doing the entire project a disservice. Content types are the backbone of a Drupal website and will be the main way end-users interact with Drupal. Start with what content will be on the site and work backwards from there. The content will dictate the fields, the taxonomies, the views, and everything in between. The result may not be an easier development but it will be a more extensible and scalable site. Your UX designer will thank you, your project manager will thank you, your end user will thank you, and your client will thank you. Presenter: Carrie Hane Dennison, Content & Usability Director, Balance Interactive
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Empfohlen
Empfohlen (20)
Putting Content First - Planning Content Types
- 2. Content First – Planning Content Types DrupalCamp Maryland February 10, 2012 Carrie Hane Dennison #DrupalCampMD #contentfirst @carriehd
- 3. I Drupal Balance Interactive Inc. www.BalanceInteractive.com
- 4. Why Should You Care About Content? • Better direction • Less guessing • Do it right the first time Balance Interactive Inc. www.BalanceInteractive.com
- 5. When You Don’t Think About Content First • Misdirection • 11th hour $^*#storm • Migration headaches • Late, over-budget projects that don’t meet needs • No content at all • Re-dos • Goals not met • Unhappy end-users who toss out the site or Drupal Balance Interactive Inc. www.BalanceInteractive.com
- 6. When You Think About Content First • Clear list of tasks • More depth to the content • Smooth path to launch • On-time, on-budget projects that meet needs now and in future • Happy end users & visitors Balance Interactive Inc. www.BalanceInteractive.com
- 7. Collaborate • Pre-build meeting – content and development leads • Pre-define content types based on the actual content of the site • Content strategist leads meeting with lots of input from developer • Go through site map and wireframes to ensure you’re covering all bases for use of content Balance Interactive Inc. www.BalanceInteractive.com
- 8. Defining Content Types • What needs to be included from the legacy system? • Review site map and wireframes – where are possible distinct content types? • Ask the client what they foresee changing • Name them, define the fields and taxonomies • Use non-technical, non-circular words to describe Balance Interactive Inc. www.BalanceInteractive.com
- 9. When to Divide Content Types • Used in different ways across site? • Many unique fields? • Used in views? • Goal: Just enough – not too many, not too few Balance Interactive Inc. www.BalanceInteractive.com
- 10. What to Fields to Include • Default - Rename fields? Include or delete? • Custom • List fields – name and type • Taxonomy vs select-list field • Labels? • Display fields? Balance Interactive Inc. www.BalanceInteractive.com
- 11. Think About End Users • How comfortable are the end users with “technology”? • Make it easy for them to update site easily with little instruction • When possible, set up fields so they do not have to format text Balance Interactive Inc. www.BalanceInteractive.com
- 12. Example Content Type Balance Interactive Inc. www.BalanceInteractive.com
- 13. Balance Interactive Inc. www.BalanceInteractive.com
- 14. Balance Interactive Inc. www.BalanceInteractive.com
- 16. Futureproofing • Today: content being transferred, some enhancements • Tomorrow: add information and relationships, new types of content, known enhancements • Ask the question: What do you see happening with this content? • Make it easy to go from today to tomorrow • Add taxonomy • Think modular • Think views and taxonomy • Moving to mobile Balance Interactive Inc. www.BalanceInteractive.com
- 17. Communication • Don’t work in a vacuum • Demand input • Ask questions and give options • Think like an end user and visitor • Be creative and push your boundaries Balance Interactive Inc. www.BalanceInteractive.com
- 18. Conclusion • Avoid snowball effect • Embrace the creativity that Drupal allows • Everyone is happy – no do overs, time for fun things Balance Interactive Inc. www.BalanceInteractive.com
- 19. QUESTIONS? Contact me: carrie.dennison@balanceinteractive.com Follow me: @carriehd View slides: http://slidesha.re/w4IhtE
Hinweis der Redaktion
- Ask how many are DevelopersDesignersThemersProject ManagersOther – what?
- I LOVE Drupal!I am not a developer, I am a content strategist. Why do I love Drupal? Because it is flexible and powerful. And I work with some awesome developers (and lots of other terrific people too!).Why should you listen to me? Because I’m going to tell you how to have more on-time, on-budget projects that meet their objectives and future-proof your website.
- How many of you work in teams to plan your build? Who is on that team? Project managers? Other developers? Content strategists?So, why should you – as developers – care about content? (Bullets)My goal is for developers to learn how to think more like non-technical, but often smart, end-users. And, to be fair, next week I’m talking to a group of content strategists to tell them why they need to work with developers and think more like them. So I’m a double agent. It is so important that everyone working on a web project speak the same language.Imagine a magazine – let’s say Sports Illustrated. It would pretty much suck without the content – and I do consider the pictures content. You don’t buy and read it because it has some cool font or you like how it is printed or because of the ads. I have not worked at a magazine, but I am certain that the content comes first. Articles start with a title, an author, and body copy. Photos and pull quotes are added. Lots of other things happen, and then it is printed. But that content also gets published to the website. That means the content needs to be displayed in a completely different way on a website. And don’t forget the mobile app. Same content, different delivery system. They don’t recreate the content for each delivery system. They have to think about the content first – what do they need for each delivery method – and then set each system up to accept that content. All websites should do the same.Let’s talk first about what might happen when you don’t start with content…
- When you don’t start building with content in mind, there are any number of things that could go wrong. Here are some of them.(bullets)Example: NASBONot planned properly – didn’t pay attention to the content that was coming overToo many content typesContent that did not provide the correct relationships between itemsNo creativity to take advantage of existing modules or content typesDevelopers who guessed – wronglyBottom line – late, WAY over budget (had to be built twice), and lots of frustration for the entire teamWe did recover, but at great cost (literally) and with much midnight oilNow let’s think about a world where you start with the content…
- Lots of good things happen when you start with content and then plan the build(bullets)Example: USTelecomContent types that (mostly) did what they needed to doComplex views (views within views)Developer who knew exactly what to doOn-time, under budget projectClient who can make modifications and continue to embrace the power of DrupalBalance Interactive has been building websites with Drupal for about 5 or 6 years. A lot has changed in the world of web development since then. I’m going to share our process for making sure content comes first and how we plan our Drupal content types for the content.
- Before anyone touches Drupal’s back end (other than setting up the dev environment and installing modules), we have a planning session. The two primary participants are the content strategist and lead developer. The project manager is consulted, and some questions are directed to the themer. (bullets)And even before this meeting, the content strategist starts to define the content types…
- We start with…(bullets)Names: short, distinct names that are easily recognizableUse words client uses for names and descriptions There are many considerations to dividing content….
- One question I usually come to the table with is “should this be its own content type?” We work with these questions and get to the decision together(bullets)Then we’re just like Goldilocks.Once we decide if something should be a distinct content types…
- As we work through each content type and views, we define all the fields, right down to the labels and whether to display fields on the node.Sometimes we have few or no custom fields, but that is all a strategic decision.We also take people into consideration…
- And by people, I mean the people who will be entering and maintaining the content. Do the editors know HTML? Does the client have staff resources to create images? Remember that many people still think of websites as “technology” and many are still uncomfortable with technology. When you make it easy and intuitive for them to enter the content, they are much happier.Here are some examples of some of a typical content types we build…
- You can see here how it is displayed. Point out fields, noderefs, template parts, body, menus
- This is what it looks like in the node edit view. WeRename the title to Page Name to avoid confusion because we always include the Page Title to populate the meta Title field for better SEO.Often include a call outSometimes include nodereferences to videos, images, calls to action
- Here is a more complicated display. Point out views, other content types that feed into them.You can see that these are fairly modular, so that they can be expanded or enhanced in the future.
- This is a seemingly simple content type, but it serves a complex purpose: it is the basis for lots of information being pulled in on a certain service offering. And because they are a distinct content type, there is room for expansion of this concept. Even more information can be related to this service offering.
- We all know that a website is never complete. Sure certain parameters are set today. But next month someone will have a new idea, and the CMS needs to be ready to accommodate without a complete re-do.And what is the #1 thing people want today? A mobile site. Building a site based on content helps turn a site into a mobile version. Don’t need that field? Don’t display it. Need to change the order of content blocks or fields? Not a problem. But if you build just 1 field with lots of formatting, that will be difficult to do. Drupal makes it so easy to create modular content. This cannot be said for every CMS.In all of this one thing is critical…
- Communication… without it, you’re doomed.(bullets)Drupal can seemingly do anything, but it takes time for some things. So consider whether it is worth the effort. Compromises need to be made on all sides. Maybe the strategists needs to sacrifice some cool auto displays for a less complicated build. Maybe developers need to figure out how to make a view display within a view.
- Some final thoughts about dos and don’ts of Drupal builds (or any CMS build, for that matter)a snowman is nice, an avalanche is notSomething I have said many times is “I love Drupal because our developers never tell me something can’t be done.” (Of course, some things come at too high a price, but they could be done.)Since you don’t have to rebuild the site next year, you can do fun things like create a new module or add some other cool functionality