![Drupal 7 ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Recomendados
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Destaque
Semelhante a Fronteers - Drupal 7 ux
Semelhante a Fronteers - Drupal 7 ux (20)
Fronteers - Drupal 7 ux
- 1. Drupal 7 User Experience Bojhan Somers & Roy Scholten
- 5. 2009: Drupal 7UX Mark Boulton Leisa Reichelt
- 8. Probleem 1 Wat is de voorkant (site) en de achterkant (admin)?
- 10. Probleem 2 Waar vind ik mijn content?
- 12. Probleem 3 Waar vind ik mijn functionaliteit?
- 18. Before After
- 19. Before After
- 20. Contextual links
- 21. Actions
- 22. Module links
- 24. Theming Drupal 7
- 25. Less is more…
- 26. Bye-bye ugly old themes
- 28. New front-end theme in progress
- 29. New admin theme: Seven
- 31. New no-theme: Stark
- 34. html.tpl.php
- 35. Page anatomy
- 36. region.tpl.php
- 37. CSS
- 41. php
- 46. And much much more …
- 53. Design in open source Few designers: pick your battles Communicating design to a large audience is hard "You are not your target audience" – 1 UX designer overrules 700 developer opinions…
- 54. Dank u! vragen? @bojhan / @royscholten
Notas do Editor
- Goedenavond, Bojhan Somers & Roy scholten - UX Maintinaers van Drupal 7 Betekend afgelopen 2 jaar, alle veranderingen op het gebied van UI Kleine, zoals tekst en grote zoals de informatie architectuur van drupal
- Er zijn heel wat wijzingen in Drupal 7… CCK in core Image handeling Update manager Rdf support Ectra…. Maar deze talk gaat voornamelijk in op de verandering op gebied van de interface en front-end.
- Drupal is best moeilijk kost veel tijd om te leren simpele dingen, kosten te veel tijd Grootste nadeel van Drupal usability veel mensen haken af in begin
- 2008 Twee usability tests pijnlijk duidelijk dat de gebruiksvriendelijkhe van drupal dramatisch was. Wake up call voor de community, en vooral z’n leaders om dit onderwerp aan te pakken eind 2008 vomd zich een UX-Team er is vanuit de community behoefte aan “erkende” experts op dit gebied ipv de mening van elke developer over de usability van een probleem
- Maart 2009 – Aankondiging Mark Boulton en Leisa Reichelt gesponserd door Acquia, een drupal support bedrijf fulltime gaan werken aan de user experience van drupal 7 Grote impact op community Veel stof opwaaien omdat ze onderwerpen aansneden, die enigszins controversieel waren Sinds maart Close samengewerkt Feedback geven op hun ideeën Goed en toegepast genoeg zijn om ze in Drupal core te krijgen Om richting te geven hebben wij toen een lijst opgesteld met de volgende problemen :
- Uit lab test kwam naar voren Onduidelijk of je in de admin zit Drupal geen admin theme, visueel is er geen verschil tussen de admin en de site. Het vinden van content, nadat deze was gemaakt (komt niet op homepage) Deze functionaliteit is toch vrij cruciaal in een CMS Vinden functionaliteit Nadat je een plugin (module) heb geinstaleerd… dit terwijl je vaak 20/30 moet instaleren on any typical site. - Ten slote, werd Drupal getesiterd door vele kleine usability problemen – die in hun geheel eigenlijk nog voor meer verwarring zorgde dan de grote; de consistencie die vaak afwezig is, veel te veel help tekst, onduidelijke labels ect..
- Door Drupal zijn technische insteek, hadden we de grootste doelgroep, en vaak ook onze client – eigen verwaarloost. De content schrijver… De focus van het Drupal 7UX van Mark Boulton en Leisa reichelt was dan ook focusen op de content schrijver.
- Vooral nieuwe gebruikers liepen tegen dit probleem op: Als je start is het niet duidelijk wanneer je in de admin interface zit, en wanneer je in de site zit Drupal 6 is dit met elkaar vermengd We zagen in tests dat de eerste paar minuten dat menen Drupal gebruiken, al meteen erg verward zijn over dit. Dit zorgde ervoor dat we veel initele verwarring over wat de admin is van je website weg namen, en ook dat we visueel veel meer consistentie en rust konden brengen in de administratie ervaring.
- De eerste groote verandering die we hebben gemaakt is dan ook het introduceren van een admin theme genaamd “Seven”. Visuele consistentie konden creëren Gebruiker word niet afgeleid door “site” elementen Rust (visueel niet druk)
- Wanneer je content creëert binnen in Drupal, heb je eigenlijk 50% kans dat deze niet op de home page komt. (vanwege pagina typen) Gebruikers hun content niet kunnen vinden Kunnen hun content niet editen Kunnen geen nieuwe content creëren Het vinden van deze administratie pagina Verstopt in de administratie
- We hebben nu de informatie architectuur dichter bij de gebruiker gebracht : Toolbar, boven aan de site Waar direct links zijn naar content, creëren van content staan Voor veel content schrijvers, is deze content admin pagina vaak het start punt..
- In Drupal 6 is het vaak moeilijk kritische functionaliteit te vinden…. Maar zoals eerder aan gegeven, is het vooral een probleem als je enkele modules begint te instaleren. We hebben dan ook de Informatie Architectuur van Drupal compleet veranderd. Drupal 6 heeft eigenlijk 1 grote sitemap, een grote dumping ground voor links…. Waarbij we 4 vrij los gedefineerde categorieen hebben, met daarin de functionaliteit gesorteerd op alphabet. En dit model bestond eigenlijk omdat Drupal, vooral om draaid dat je functionaliteit kan toevoegen zonder de core te hoeven hacken. Daardoor kon je niet bepalen, welke functionaliteit het belangrijkste is of welke met elkaar samen werken. Hierdoor onstonden er allerlei problemen, mensen kunnen functionaliteit niet vinden – maar voornamelijk functionaliteit die je in combinatie met elkaar gebruikte stond soms mijlen ver van elkaar vandaan.
- Drupal 6 1 grote sitemap grote dumping ground voor links 4 los gefineerde categorien De functionaliteit gesorteerd op alfabet. modulaire informatie architectuur geen aannames maken op welke functionaliteit belangrijker is. Dit model - allerlei problemen - Als je een bepaalde workflow had, waarbij je meerdere modules nodig had Over de gehele pagina moest scannen constant, om het te vinden Geen verwachting patroon in voor de gebruiker, vaak zagen we dat die resulteerde tot de browser search om deze pagina te gebruiken. Nieuwe informatie architectuur – ik zal er enkele behandelen
- Content pagina, waarop je gewoon een listing heb van je content.
- Structure is waar vaak gebruikte functionliteit die je tijdens het bouw process gebruikt komen. Dit omdat deze vaak gebruikte wat af te scheiden van configuratie opties.
- Ten slotte de Configuratie pagina.. Deze categorie was in Drupal 6 eigenlijk een grote lijst, met soms 30 tot 40 links. Dit was eigenlijk de grootste uitdaging, deze pagina heeft namelijk als doel om de functionaliteit van 20/30 modules die kunnen worde geïnstalleerd logisch in te delen. En deze 20/30 modules hangt geheel af welke van de 4000 bestaande modules worden geïnstalleerd. Na het analyseren van deze grote group modules, hebben we categorieën gemaakt Anticiperend op de modules die nu niet meer van belang zijn (omdat ze in core zitten) Modules die belangrijk worden in Drupal 7, zoals fields, RDF ect
- De vele kleine problemen zijn op te delen in twee onderwerpen… Tekst, copywriting in Drupal – is vaak gefocused op het zo gedetaileerd mogelijk uitleggen wat de functie doet, en het onsluiten van alle edge cases…. Eigenlijk veelal probeerde de tekst een slechte interface op te lossen. Workflow. - Vooral de navigatie naar functionaliteit waarbij je de context verloor.
- Drupal heeft heel erg last van het fenomeen Omschrijving Puur alleen om het hebben van een omschrijving Elk field moet een beschrijving onder komen staan Toen we dit hadden verwijderd – konden we deze kleine winst, waar iedereen mee eens was gebruiken als patroon in Drupal
- Nog voorbeeld – Taxonomy pagina Een hele lap met tekst, scrollen om bij de functionaliteit te komen In de lab test Gebruikers die de tekst lazen, waren meer verward dan die werkelijk het probeerden te gebruiken Reduceren Twee regels tekst ONTO: Workflow
- Concept, dat we steeds meer in de community ontwikkelde modules zagen. Contextual links Acties die gerelateerd zijn aan het object waar je over heen hoverd met je huis. Tools dichter bij je te brengen Vaak kost het je 4/5 kliks om bij de juiste administratie pagina te komen Verlies je de context die nodig is.
- Wat uit de gebruikers testen bleek Meeste moeite met het onderscheiden van de listing tabs en de ene actie. - Dit koste per actie, vaak enkele seconde extra
- Elke keer als je een module installeert moet je deze configureren en de permissies zetten. En zelfs met de nieuwe informatie architectuur, kost het vinden van deze toch nog wat tijd. Daarom hebben we ook besloten om deze links, veel dichter bij de workflow van het “instaleren” te brengen. Want zelfs ervaren Drupal gebruikers vergeten de permissies vaak te zetten.
- En dan hebben we eigenlijk nog niet eens alle ux features gehad… We hebben onder de toolbar, een aantal shortcuts zitten die je per gebruiker van je site kan instellen. We hebben een dashboard…. We hebben een default profile en dus ook een non-default, waardoor developers gemakkelijker met een empty shell kunnen beginnen En nog een tal van kleinere verbeteringen…
- Ok, dan gaan we nu de belangrijkste veranderingen voor fronteers en themers op een rijtje zetten
- Om maar te beginnen met de eerste indruk... Als je nu D6 installeert heb je de keuze uit een paar pre-historische themes. Echt voor elk wat wils…
- Bijna alle oubollige themes zijn uit core verwijderd. (Voor de liefhebber nog steeds verkrijgbaar in contrib) Dat ruimt alvast aardig op. Maar er zijn ook nieuwe themes toegevoegd…
- Garland is de afgelopen twee versie het standaard theme geweest (front en back-end dus)
- Er wordt hard aan gewerkt om ook een nieuw standaard theme voor de voorkant te introduceren. Is nog werk in uitvoering
- Seven is het nieuwe standaard admin-theme. Zoals Bojhan al aangaf neemt een admin theme een belangrijk ux struikelblok weg. Maar het biedt ook voordelen voor de themer, die zich nu tot het vormgeven van de voorkant kan beperken.
- Goed, dat zijn de kant en klare themes. Maar in 99,9% van de gevallen wil je natuurlijk zelf iets maken. Drupal 7 biedt frontenders een aantal nieuwe mogelijkheden voor het nog beter customizen van de standaard Drupal HTML, CSS en JavaScript output. Daarvoor moet ik jullie nog aan 1 extra nieuw core theme voorstellen…
- Het is niet gemakkelijk om inzicht te krijgen in welke html en css waar door Drupal gegenereerd wordt. De templates die de html genereren en css bestanden zijn over allerlei module-mappen verspreid. Om front-enders op eenvoudige manier inzicht te geven in de default HTML en CSS die core levert is Stark theme geintroduceerd. Stark voegt GEEN styling toe behalve wat positionering zodat je makkelijk met je browser en Firebug kunt rondneuzen.
- Stark is daarmee niet alleen een handige tool voor nieuwelingen die de frontend output van Drupal willen inspecteren. Het was ook een flinke stok achter de deur voor de community zelf om de boel eens flink onderhanden te nemen. Want die default output blonk niet echt uit in semantisch minimale pracht. Tijdens de ontwikkelcyclus van D7 is er dan ook meer dan ooit activiteit geweest rondom het opschonen van Drupal's default output. Laten we de meest belangrijke veranderingen doornemen:
- Even in het kort iets over hoe een Drupal pagina tot stand komt. Modulariteit is een kernwaarde van Drupal en dat vind je ook de theming layer terug. Een pagina bestaat uit een flink aantal verschillende template bestanden die elk een deel van het renderen van de pagina op zich nemen. In core zijn iets van 40 van dit soort templates te vinden. Contrib modules die zich met de weergave van content bemoeien voegen daar nog weer extra templates aan toe. (doornemen) Regions zijn de main containers in je page – header, sidebars, content, footer etc.
- Bijvoorbeeld de nieuwe html.tpl.php (voorheen was page.tpl de main wrapper om alles) Je ziet hoe hier eigenlijk alleen de doctype en containers voor head en body gedefinieerd worden (page_top en page_bottom zijn special, hidden regions) in $page wordt de inhoud van page.tpl.php getoond…
- Na page.tpl.php komt region.tpl.php. Da's een heel eenvoudige
- Een heel simpel template voor de wrapper om de hoofdonderdelen op de pagina zoals header, footer, sidebars en content Mocht je dus je eigen html voor elke region willen definieren, Bijvoorbeeld omdat je altijd een div en een div-inner wil gebruiken zodat je margins/paddings aan de -inner kunt toevoegen zonder de box model te breken (I know, I know… :-) Ddan maak je in je eigen theme je eigen versie van region.tpl.php aan.
- En zo zijn de meeste core tpl.php bestanden grondig herzien. De default is nog lang geen superstrakke lean & mean semantische html maar duidelijk verbeterd. Goed. door naar de CSS Echt een tak van sport die onderbelicht is/was in de Drupal community. Gelukkig begint ook daar verandering in te komen en heeft D7 aantal flinke stappen in de goede richting gezet.
- Nog even terug naar de region tpl.php. Nieuwe feature is dat je aan elke tpl dynamische classes kunt toevoegen. Dit maakt het mogelijk om slimmere, 'context-aware' classes toe te voegen die je dan naar believen kunt stylen
- System.css is zo'n beetje de moeder van alle CSS bestanden in Drupal. En het is echt een halfbakken mengelmoes van borders en margins en paddings etc. Meeste themers kicken system.css het liefst geheel uit de rendering. Lullige was dat er ook een paar styles in zaten die cruciaal waren voor het functioneren van een aantal ui componenten. System.css is nu zodanig opgesplitst dat het makkelijker wordt om de presentatie styles in zijn geheel te verwijderen zonder dat je functionaliteit breekt. Er zijn plannen om dit ook voor contrib modules de standaard te maken: module.css module-behavior.css Hierdoor hoef je geen wanstaltige reset.css telkens weer bij te werken maar kun je zonder zorgen alle presentatie styles verwijderen uit de rendering.
- Ja, nog een teken dat er meer waarde wordt gehecht aan de front end code: Drupal's code staat bekend om vrij hoge kwaliteit van de code. Strikte regels voor hoeveel spaces een tab mogen zijn, hoe comments geplaatst worden etc. Nog niet iedereen is het er mee eens, maar er begint zich ook een standaard voor Drupal's CSS notatie af te tekenen
- Tot zover de CSS onderwerpen Nu een aantal van de belangrijke veranderingen op php niveau
- Ok, je bent op het punt aanbeland dat je een content item (node) wil gaan weergeven. Die content zit in de $content variabele, een array met daarin alle info over titel, body, het plaatje, de tags etc. Nou wil je die items natuurlijk wel eens in een andere volgorde tonen. Dat kon op zich al, maar installeerde je daarna nog een module of definieerde je zelf nog een extra veld voor die node, dan gooide dat die array overhoop en moest je alles weer opnieuw nalopen. met de nieuwe hide(); en render(); functies is dat verleden tijd en is je custom rendering dus 'forward compatible'
- Je kunt vanuit je theme al vrij veel dingen overriden, maar customizen van admin en andere formulieren hoorde daar niet bij. Daarvoor schreef je dan een kleine custom module met daarin de gewenste aanpassingen. Vanaf Drupal 7 zijn deze zogenaamde hook_alters ook vanuit je theme inzetbaar Geen nieuwe functionaliteit per se dus, maar een uitbreiding van de mogelijkheiden vanuit je theme . De laatste twee spreken redelij voor zich. We bekijken een voorbeeldje van een hook_form_alter
- Probleem: Je wil de buttons voor het commentaar formulier een ander label meegeven en er wat html omheen zetten zodat je ze in z'n geheel makkelijker zou kunnen positioneren.
- Dus, dit is het beoogde eindresultaat: Andere teksten en een divje eromheen voor positioning. Daaronder de code die dit mogelijk maakt. - 'pretty' is de naam van je theme - 'form_comment' is de id van het formulier Nu moet je voor dit soort zaken dus nog een custom moduletje schrijven. Vanaf D7 kan dit vanuit je theme. (Nee klopt, niet het meest zinnige voorbeeld maar het gaat om het principe nietwaar?) (Als je Save en Preview zou vertalen dan gebeurt dat op elke plek waar deze termen gebruikt worden dus dat zou niet werken)
- Nog wat kleinere zaken die fijn zijn als je al bekend bent met D6 Voor nieuwkomers als het je al wat zegt zijn het vooral vrij obvious dingen waar Drupal wat minder eigenwijs is in hoe zaken aangepakt worden
- Eerste helft 2010… Maar voor productiesies zit je nog wel tijdje met Drupal 6. Wie is er hier nu al een Drupal themer? Veel van deze discussie vertaald zich naar contrib modules, die zijn nu eenmaal sneller te realiseren. Dus ook voor Drupal 6 zijn er voor fronteers tools beschikbaar om nettere front-end code te genereren.
- Mothership is een zeeeeer grondige reset van core CSS en HTML CSS classes worden gestript en core CSS files worden overschreven of uitgesloten Alle core tpl files en een aantal van de belangrijke voor contrib (views, cck) zijn erin verzameld en herschreven met minimale HTML Gebruik Mothership als basetheme en hang je eigen subtheme eronder waarin je de gewenste classes en id's weer toevoegt.
- Zelfde verhaal voor de output van de populaire Views module Semantic views module is een 'row style' plugin voor Views waarmee je de html en classes die voor elk item in de view gebruikt wordt kunt definieren
- De laatste link is een intro op hoe zelf themes te maken die zich wel baseren op de default html en hoe je daar met vooral CSS mee kunt vormgeven.
- Wat links naar docs en een presentatie
- Maar waarom wij twee hier vooral zoveel energie in hebben gestoken is dat we beiden overtuigd zijn van het belang van design in open source projecten. Wat het Drupal 7UX project vooral bloot legde, is dat we eigenlijk voor de verkeerde target group ( die van de expert user) aan het designen waren. Die expert user ( de developer) is natuurlijk het meest aanwezig in de gesprekken over het verbeteren van een interface. Het is dus aan de designer om 700 expert meningen tegen te houden en zich op te stellen als de vertegenwoordiger van de 700.000 end users die dagelijks moeten werken met de site die de experts voor ze gebouwed hebben. Het duurt even voordat je dat vertrouwen gewonnen hebt… Want de preferred solution in OS user interface design is om in geval van twijfel niet zelf te kiezen maar het een optie/preference te maken. Terwijl de UX designer nou juist probeert de gebruiker zo min mogelijk te vermoeien met 'stuff' en erop hamert zelf deze keuzes al te maken. Met Drupal 7 is ons dat op belangrijke punten al aardig gelukt. De tijd zal uitwijzen of we het bij het rechte eind hadden :)