This blog post is a collection of thoughts and notes from discussions, birds of feather sessions at Drupalcon Munich, from the perspective of a UX/front-end designer. These notes should be most useful for small to medium-size teams interested in improving their capacity to leverage Drupal as corporate/middleware solution, improving their workflows and understanding the main things happening in the UX space in the Drupalsphere.
We've tried to collect as much information about the BoF discussions as possible because they weren't filmed, and notes are really hard to come by – although most of them were really extremely useful and noteworthy, covering topics from Agile approach to UX, building social intranet and extranet websites, integrating Drupal into corporate infrastructure and using it as middleware to gather data from disparate data sources and much more. Please share, comment, and tweet your thoughts @thinkfabrik – thank you! :) The photo above is a photorealistic depiction of people surfing the waves
of Drupal in Munich, summer 2012.
By Nikolay Borisov and Ulf Sthamer / T-systems
Description from Drupalcon website:
Each day key words like Social Business, Social Collaboration or Social Intranet are gaining more and more importance for enterprises. A few years ago those topics were only relevant for large enterprises. Today the time has come for SMEs to think about structuring their internal working environment by using a social intranet or providing an external community platform to their customers. Since those smaller enterprises don't want to spend their budget on commercial licences, they need to evaluate low-price alternatives.
Within this BoF-Session we would like to discuss the opportunities of Drupal on the Social Business market with you.
The session will beginn with a presentation, in which we will give a brief introduction to Social Business with a focus on Social Intranets.
Then we will present the top 5 prioritized requirements of a social intranet from our experience and will then discuss how Drupal manages to meet those requirements on the example of Drupal Commons.
After stating the advantages of Drupal, in the second part of the session we would like to make an open discussion on which gaps need to be addressed by Drupal on their way towards a Social Business plattform and afterwards gather new ideas to make Drupal as mature as possible for the enterprise market.
Social systems with Drupal - intranet /extranet
- Building sites based on Drupal commons distribution
- use cases: one to many communications and collaboration
- many to many: knowledge/experience sharing
- three goals: inf and official communication
Collaboration and projects
Networking and communities
- social component of intranet and extranet is merging
- use cases:
Static intranet (hierarchical information organized as a db/knowledge base) - maybe as a book module for groups?
Group and project rooms
Profile and networking
- commercial solutions (such as Jive) offer much of this functionality but miss e.g. hierarchical book knowledge bases, and it costs a lot to add/implement anything later
- dashboard/user homepage: the first page activated for user upon login (implemented well in drupal commons)
- expert search: personal profiles of users with info about skills, common groups with you, interests, 'ask me about' section, recent activities, follow button, contact form
- project groups: featuring specific project info, updates, q&a. Problem: no granular per-project permissions
- mobile web or apps. Mobile support coming soon in drupal commons. Drupalium in titanium. mobile theme in drupal commons is coming
- people search: solr search in profileplus etc
- bof participants: halabul social change community from india, canadian government, acquia, austrian eu-austrian relationship body/ govt dev guy,
- problem: adding a simpler registration and login and simple starting guide (like a checklist for new users?)
Takeaways: making the system match users' workflows; don't overload the UI; don't take shortcuts simply because “there's a module for that.'
TDD/BDD (test-driven development/behaviour-driven development for Drupal)
Our session notes:
Mink+doobi (Drupal extension) http://drupal.org/project/drupalextension
Spec bdd: http://drupal.org/project/spec
Getting clients to sign the test scenarios
Php for unit testing. - upal
Selenium tests can be slow
Connecting via drush to login and to to create a user and then deleting it to clean up after all
Acceptance testing vs unit testing: looking at the pages and interactions vs clicking and checking the logic
Bdd - writing a nice scenario as opposed to reusing a bunch of scripted step definitions. E.g. With spec bdd
The point is having nice readable specs and then adding testing code.
Came via ruby :)
Good to have alternatives though with cucumber vs spec bdd etc and Dolby
Testing Drupal.org happens with mink and with Drupal extension
Bdd is a subset of tdd helping to anticipate errors that programmers can't anticipate
Simple tests are the de facto standard but it is a lot of code and is a technical
Simple tests may involve cloning the db and creating a new site.
Async fixture db - e.g. With a drush and features vs writing setup files
Example: every test includes a login function. This can be done programmatically in drush to save time.
Headless browsing is much faster than selenium
Writing tests is a craftsmanship, takes a lot to get productive, but helps to become a better developer
tests aren't fun but they inspire confidence. Clients need to be sold though. 40% can be reused from Drupal project to project.
Tests take time to build and to run, and halF of the time they fail because the test was written incorrectly - with simple tests. With behat though it doesn't happen!
Spec with helper functions
Leveraging Drupal to initiate a change
From Drupalcon website:
India is witnessing a growing sensitization in its citizens regarding the need for a change. More and more citizens are willing to challenge the status quo and take required actions to bring about the desired social change. They are restrained from contributing for the lack of proper medium or tools to direct their efforts or resources towards their social objectives.
We would talk about Sonali Mukherjee - an acid attack victim - and how a Drupal platform was able to help her out by garnering support for her - financial as well as moral. An online petition for her was able to garner > 4.5K signatures in just a matter of 3 weeks, a substantial financial amount in her bank in collaboration with wishberry.in and above all - a sensitized audience.
The petition was hosted on Halabol. (http://petitions.halabol.com/2012/07/15/justice-and-life-sonali-mukherje...)
The agenda of this BOF is :
* Drupal for a change
* Halabol Platform
* Open Discussion
In this session we would like to meet with like minded people who want to / have been working in this domain to discuss out the various possibilities/ synergies. If you make or want to make websites that have a social impact, that make people conscious/ perceptive, that help people connect to one another to bring the change they want to see...join us.
- Case study of halabol.com which is a community website based on Drupal commons
- a petition gathered 5000 signatures in three weeks, and collected 10 000 000 rupees in help for a woman who was a victim of an acid attack and the police did not interfere although she named the attackers
- using noded references between ideas and campaigns and events, so that people can organize themselves
- Facebook app in works to post campaigns and events automatically from site to Facebook
- using cck signup module for events
- get directions module for Drupal events/google maps
- Drupal commons q&a for a debate/ideas section
Mothership by mortendk
for the 7 seas of Drupal!
From Drupalcon website:
Submitted by mortendk on August 6, 2012 - 20:23
the The mothership theme is markup anal (lets say it as it is)
The project concept is build upon removing divs, changing markup & making the souce code look like something that a frontend dev would write in hand.
The idea about this bof is to get some likeminded html junkies, themers, frontenddevs etc to sit down n talk about the possibilities & how to use the mothership as a base for pushing the markup to a new & better level.
Ill try to layout my ideas for the future & hopefully shanghai a geek or 2
Cause lets face it Drupal will never ever make perfect markup, the issueque is simply to long & harsh ;)
* Why Drupal is wrong & why it will be that way forever.
* Who should use the mighty mothership & when
* Whats the battle plan
* What about D8 & that Twig thing
* How do we make the markup better in Drupal ?
* Total markup control - is that a goal?
* Design ? why it looks like nothing
Our session notes:
Turn off form, table, views classes and extra markup
Turn off extra js and CSS
Put all CSS in ONE file per site instead of several CSS files loaded for each page
Couldn't remove the feed links making them CSS instead of image as they were in system.
Removing clear fix from blocks etc - which couldn't be overridden previously
Jqueryupdate and other Inge that are always needed by default
Semantic panels as an idea?
Developers are not all completely evil :)
Blog module is getting redesigned?
Forum module, blog, feed, block declaration/clear fix markup should die
How does spark affect theming?
Theming: Dominate The Theme Layer
From Drupalcon website:
Drupal's theming layer is a powerful and beautiful beast, but it requires a firm hand to really behave. New themers often start out trying to control it with a light touch and gentle strokes of CSS. Only too late do they realize their error…
Don't let Contrib bully you around. Grab the reins, create a frontend architecture and teach the theming layer to produce lean, extendable, high performance markup and CSS that is easy and cost-efficient to maintain.
This session is about learning to take charge.
In this session
Techniques and workflows for domination.
Principles and benefits of a CSS architecture with inspiration from object-oriented CSS and SMACSS.
Base your frontend on relevant design and business goals instead of back-end architecture.
Designing your frontend for extensibility.
Avoiding common pitfalls and dangers when working with Drupal.
Tools of domination
The session will supply attendees with a range of useful tools and techniques of domination to make the beast behave, including preprocess functions, theme function overrides and templates.
Tools are available at Github.com: https://github.com/woeldiche/domination_tools/
Feel free to fork, comment or send me pull-requests with improvements and bugfixes.
main steps - not trying to fit the design to drupal's building blocks/modules, but actually understanding the logic.
- find logic
bring the designer onboard. and a strategist on board
- disucss everything over a coffee
- streamline variation of common objects - things that are almost identical but have small differences - ask the designer why and try to reduce the number of unneeded patterns
- OR: define rules for the variations
- define objects from patterns
- smacss - scalable and modular architecture for CSS
- a suggested system: variations, style, typography, structure, grids
- have a system, and write it down - really helps! e.g. .title-field /* headings and labels for download, select menus etc*/
- use low specificity - make classes as broad as possible
- layer your objects
- its a matter of class
- get everything fixed in views (75% of styling), and then do the rest in render arrays
- multi fields
- forms (the only thing scarier than ordinary render arrays)
- conclusion: gentle touch is not always the best. dominate your markup.
a really well-structured talk for improving theme markup and making themes better, simpler, easier to implement and to maintain.
Selling Drupal & Web Experience Management to Large Enterprises: Choose Your Battles and Choose them Wisely
In many large enterprises, Drupal is becoming a bigger threat to legacy enterprise content management systems. When approaching these enterprises to suggest Drupal projects, development teams often face an unfair fight. In one corner are the large, enterprise CMS players and their dedicated, expensive, powerful selling teams, and in the other corner is the development team shouting over the noise to promote the benefits of Drupal.
The CMS players have their arguments fully mapped out. A development team promoting Drupal must be prepared to hear arguments against its security, support and performance, most of which are just plain false.
Drupal developers are unique in their view of content as a strategic asset, and by promoting how the team helps clients optimize their content into a Web Experience Management (WEM) strategy shared by marketing and IT, this argument can put Drupal ahead of the pack. Moving to the next step, if Drupal development is combined with a high-performance team that is constantly reevaluating the project and communicating with the client, then the WEM strategy can be maximized to provide the greatest benefit to the client and their target audiences, giving the Drupal argument another advantage over legacy CMS.
If a development team sticks to the “Drupal facts” when promoting the platform and highlights the WEM benefits that the client can expect, this will help the growing Drupal community be heard even louder than before.
However, not every battle has a winning outcome. There is no silver bullet and not every enterprise will be willing to rise above the legacy CMS noise. A development team must know when current Drupal limitations will keep a specific enterprise from achieving its goals and move along to another company whose project can benefit from Drupal and the support of its growing community.
In this session, I’ll share experiences as part of a Drupal development team. I’ll discuss how Drupal can help optimize a client’s WEM strategy, arguments against Drupal that development teams can expect to hear, points development teams can highlight as they promote Drupal to new customers and how to know when the team should cut their losses and move on to another company that will profit from Drupal’s benefits.
frubim / ciandt.com
Become a specialist in CMS challenges for the Enterprise:
Multiple sites management (aegir?)
system development lifecycle process(Drupal helps both agile teams and waterfall ones to achieve their goals)
- Master what drupal has to offer to the enterprise world
- demonstrate Durpal's tremendous flexibility
- show drupal's innovation rate (a module for google+1 in a matter of days after google's introduction). time to market is incredibly short! no need to wait four months for next release. We can do a module for almost any single feature in a week :)
- improved content authoring capabilities
- security: as secure as the team that's working on the site. Security reviews done by the drupal review team (40 people) releasing frequent security audit results
- performance? performance is doing well, thanks for asking!
- drupal roadmap influence: we can be a part of the next release as a large organization :)
- prepare a demo drupal site - configured for the WOW effect (not a vanilla site!)
- team-up during pre-sale
- know when to give up
Using Drupal to Build an Application, Not a Website
Porter / professional services Acquia
My average monday typically begins with the following statement from this week's client:
"Our management wants us to use Drupal, but we typically build applications, not websites. Drupal is a content management system, not an application framework. How is this going to be useful to us?"
When I hear this, I now realize that I'm left facing the task of helping yet another team make the transition from thinking of application data as "not content" and helping them realize that everything is in fact content no matter what it is. What really matters is how you use that content!
Personally I love this kind of challenge. Typically applications are in fact 100% the opposite of a Drupal site. They do 'crazy' things that are unheard of in the Drupal community. Things like:
1) 100% authenticated traffic. contrast that with the fact that most Drupal websites are 95% anonymous!
2) Applications have a lot of sensitive information that access must be very tightly controlled. Most websites show just about everything!
3) Applications manage tremendous amounts of data for very short periods of time. Websites with node counts in the millions exist, but are relatively rare.
In this session we'll discuss why drupal is actually a fantastic application framework. I'll go over the concepts, tools and short examples I use when teaching teams how to start the process of building an application using the Drupal framework.
Of particular interest to most people that would enjoy this presentation are the following:
1) Hiding everything. Starting drupal off with the strictest access to content possible
2) Developing user and group permissions and understanding access hierarchies
3) creating complex data objects that have interdependencies on other objects
4) how to gather and disseminate data from and to disparate systems
#Application vs website.
an application processes information; a website presents information. Apps have well-defined workflows, security requirements, access lists
# the data model: entity types
#entities: objects in the data model
content types - most of the data model will consist of these. try to resist the urge to use webform
treat your data as content
contact us > instead of webform,
vocabularies are an important entity type
files - static assets
there are special access rules for files related to nodes
the entity relationships are exposed as views relationships (view > advanced >relationships>entity relationship)
- when building always name relationships MAKE SURE YOU GIVE it A MEANINGFUL DESCRIPTION/IDENTIFIER
understand the direction of relationships (e.g. does the Ship entity know which Equipment entity it has equipped on it?)
- complex fields have combinations of attributes not supplied by core
relevant modules: field_group_multiple, field_collections (works within content edit screen).
Applications can connet to different directories of users - e.g. LDAP/active directory
frequent ask: CAS
little known: siteminder
# regulating access
- org hierarchy (by department etc) is the most common access regulation requirement.
usually: organic groups 99.99% of the time, and Taxonomy access control TAC .01% (allows to set non-mutual access rules - e.g. accountants can access the HR group data, but not vice versa). TAC follows taxonomy hierarchy, has nice new interface.
- role-based hierarchy is second-most common access regulation requirement. Try awesome Workflow module! Downside:
- last resort: combining two different access systems, coding own connector between them.
# Displaying the Data
- always expose data for views (just 8 lines of code required)
- watch presentation on architectural overview of views for devs at drupalcon denver by Bevan
# eat your own dogfood
- act as your users when creating forms etc
# use caching (e.g. authcache), views caching, apc, memcache etc
# use XHprof - watch Mark Sonnabaum's tutorials on how to use it - helps to identify weak spots
- use new relic - e.g. 50s to 1s page load time by using real_path_cache fix and local doc root fix
think the app through
dont write (too much) custom code
user inputs: use field validation for proper and usable field validation messages
2012.08.22 OpenAtrium BOF
upgrade phases to drupal7:
- blog, book, permissions (on a per-organization basis vs current per-person system)
- base theme (more than one base theme)
- case tracking
- Upgrade will be finalized in the coming months. Community participation is needed and welcome, head to https://community.openatrium.com/ to take part in the UI, dev and other OA initiatives!
DRUPAL AS MIDDLEWARE
as an Enterprise Service Bus
From Drupalcon website:
Acquia, EvolvingWeb, SugarCRM, Trellon
No website is an island. The days of brochureware are over and now customers want their sites to provide information about customers, finances, employees and other large data sets.
Drupal has expanded its role beyond CMS to also become an enterprise service bus- a middleware tier that connects all of these disparate systems together and then serves the relevant information within a logical business process.
This panel will explore case studies where Drupal integrates with business solutions and backend system to deliver complex, relational data through a streamlined, user-friendly front-end. Panelists are from Acquia, Evolving Web, SugarCRM and Trellon.
using drupal to integrate corporate systems:
it is a great glue to create a nice user experience
cases: search with solr
feeds module and services module as ideal interfaces for corporate systems
operations with entities (e.g. updating 100k records) without node_save as entities is much faster and more efficient. also entities have all proper fields and properties that you need defined by you
sometimes when different systems are integrated, people think of the best way to do it as importing all stuff into one central db - but that harms flexibility and isn't always event efficient if we need data just to perform a check, process for some analysis, and then maybe discard it without storing -
views3 can connect and get data from non-sql data sources
views over solr - exposing solr data from other sites etc - search results as views
using mashups of different structures
BEST PRACTICES IN DRUPAL DEV TEAMS
new tech? do a demo!
there will be specialists in particular areas
mobile team needs to do demos as well!
using redmine or jira vs a drupal-based solutions? not reinventing the wheel, also benefiting from other people's work and communities and lots of research (e.g. done by jira)
trello is nice for small things, but there's no integration with other things yet
there are presenters and synchronizers :)
coding standards / jenkins
Description from Drupalcon website:
Everybody wants to be Agile nowadays. And many companies are successful in introducing Agile development practices. However, in almost all implementations, the UX people get left out of the process. Please join us and share your experiences with Agile UX (if you have any) or learn from other people who have successfully implemented UX in an Agile organisation.
Developers need to know what the specs are agile process is hard to reconcile with stable ux documents
Maybe the styleguide should start with general objectives - we want our workflow to be incremental and easy for customers, delightful rtc
Coding with agile: good tests are key. Otherwise it is just about cutting corners
With design: know what you are trying to achieve and test and iterate
How do you measure it?
What is the litmus test of good ux?
Customers like it? Developers get it?
Maybe we need to separate how it works from ux
We can measure how well people understand and interact with the system though
e.g. Checking which shade of blue gets better conversions (google)
Maybe each project needs several kpis and several resource measurements, one of which is COMPLEXITY - including interface complexity
Don't spend more than five mins on napkin sketches and then go to testing immediately
Agile is not fast, it is slow! Thoughtful, deliberate, like slow food, artisanal
Lean seems to mean fast- no, instead it is slow code (also in a good way)
Test earlier rather than later
Political bull that happens in some organizations communication is restricted and e.g. In waterfall devs aren't allowed to talk to clients or stakeholders etc. agile at least solves that
there's no failure, only feedback
As a small team we must know our strengths and weaknesses and constantly question them both
Set up a testing lab. Start testing Thursdays. Ask everyone in the company to accomplish certain simple tasks in a product.
Agile ux means pushing tiny measurable changes, and testing e.g. Number of people who get from homepage to a certain video
Designing good tests - that's what matters in agile. Prepare the, and reuse them and Run them every day!!!
Agility is not just touchy-feely stuff, communication and collaboration, but actually measuring and testing!!!
If you are doing half of it you aren't doing it!
Spend time on GA
But not all clients obviously get it
Agile is a waste of time for small well defined projects with tight deadlines
Level of commitment is - do you want to commit to three years of iterations, testing an checking ga after each change and checking stats after three months, suggesting changes and checking the results - so the release isn't a week, but three months
If client doesn't have a budget, touch base three months after Launch and check what isn't working and suggest measurable changes
Testing, understanding and measuring
Fight for MVP, ask to cut 90% of features, ship it, and measure it and evolve
iPad is the example!
Not building MVP is not delivering full value. While you waste time on extra features the market changes. Are you sure that in product life cycle of three years nothing will change?
However, clients and product owners have a problem with that - they often take it personally
Hower, ux is not just interface. It is also pr, ads, news, leaks, what the president of the company said
This is a major company culture shift
If you ask pr people for a press release, ask first - what's your test for it? Takes years to make them understand and start following this rule
Two halftime people are more valuable than one full time
You have to test later anyway - agile helps to test early. Clients may buy in after a while if not initially
Don't use testing if you go up on the management chain
Use measure, feedback - and use bigger letters!
Lessons in government contracting, for fun and profit
Description from Drupalcon website:
Over the last 6 months Evolving Web took on a major engagement for a Canadian government agency, and learned (sometimes the hard way) just how different government consulting is from the other enterprise Drupal projects we've previously delivered.
To animate this BOF, Evolving Web's co-founder Alex Dergachev will share what we've learned, with observations on the following topics:
* Accessibility (ARIA, WCAG, WTF)
* Revision tracking and editing workflows
* Common look and feel
* Technical and hosting constraints
* Changing attitude to open source in government
* RFPs, security clearance, and the the confusing world of contracting vehicles
* Effective ways to get government work
Come learn from our experience, and share your own stories.
Working with government, pay attention to requirements for accessibility;
Selling point: no other system has the same level of community support for accessibility features and testing
Accessibility can be a key factor in negotiations with clients: don't reinvent the web, there are proven accessibility and ux patterns
E.g. Drupal commerce is a bunch of entity relationships and fields so it uses core functions for us and you build on top - hence no problems with accessibility
USC accessibility testing tool studio toolbar for Firefox
Building for the editor experience
Description from Drupalcon website:
The editor experience is somehow a blind spot in a lot of projects.
For most websites a lot of efforts go into building a good user experience for site visitors and we also put a lot of work in functionality, but very often we are missing out on usability for editors.
There are a lot of sites that are used extensively by editors and for them the “frontend” is the “backend”. The out of the box functionality just isn’t enough, to make them love to work with Drupal for content management.
In this session I want to show, what modules and techniques you can use right now to build a way better editor friendly interface.
This is a modified version of the session I held during FrontendUnited Conference (http://frontendunited.org) and DevDaysBarcelona.
The focus for this session will be more on sitebuilding, strategy for information architecture, building editor friendly forms and an overall interface that focuses on an editor's needs.
Common pain points in content management
Modules you can use to build an editor friendly backend
Strategies for the “intuitive” interface
Customizing the content admin interface with the editors in mind
Making admin interface editor-friendly!
First tip: adding rules+forms for hiding fields that aren't useful for certain user roles or use cases (or setting default rules) (like view modes for forms)
project: elements http://drupal.org/project/elements
a config for all forms
node hierarychy: creating hierarchies of content (plus menus and pathauto urls) http://drupal.org/project/nodehierarchy
menu_editor http://drupal.org/project/menu_editor for creating MUCH better menus for editors much faster!
how about adding a + button to the action links for each node to add the same content type node by editor
taxonomy_menu kills performance -> even if there's no menu on the page (menu blocks loaded the whole menu and then threw away unneeded items)
- example: hide everything on node add form except for title and boyd under vertical tabs (images, slideshow, metatags etc) - http://lipa7.deliciouscreative.com/
- the node add screen shouldn't be radically different (unless it is distracting) from the final page - as a preview?
- in the future, vertical tabs could collaps into accordion-type menus
Notes in the Google doc from the session - group-edited by participants:
Content creation and editing
rules forms support to take control over the interface
node form columns
Text editing / WYSIWYG
- users should not have to choose between text formats. better to fix it per content type or per field. “better formats” module?
- some of us don’t like wysiwyg, and go with bueditor instead, to avoid the client messing up.
more shared ideas and questions
- htmlpurifier instead of core html filter -> who does that? (donquixote does)
- how to combine wysiwyg and bueditor?
- how to combine linebreak filter and wysiwyg?
- is markdown suitable for a client?
Menu editing, with content creation included
Navigation for content editors
one way is to use quickbar with the navigation menu, and manually add additional links one might need.
TMGMT and multilingual Drupal
Drupalcon website description:
TMGMT team and discuss about the project, its usage and its
Whenever you feel involved in projects with language translation issues, you should join us.
Our audience is broad:
- need to cover multilingual workflows
- want to develop a plugin for TMGMT
- have contributed to TMGMT
Language Service Providers
- If you have integrated TMGMT already
- If you want to integrate TMGMT and expand into the Drupal world
- If you're working in the translation industry, let us know about your requirements!
- If you work as translator within drupal projects
- If you need to manage multilingual projects (and who doesn't here in Europe?)