Usability is the ease of use and learnability of a human-made object.
Source: Wikipedia
"Our ambition is to help improve the usability of Drupal for all user roles
– from core developers to anonymous site visitors"
What we would like to do (long term goal)
A key measure of good design in both code development and user experience is the degree to which a solution can be applied successfully to multiple contexts. The opposite of this is evident in systems that involve habitually re-written code that ultimately shows up as inconsistent and fragmented user experiences.
We are announcing, here, a community initiative that will tackle some of Drupal’s deeper usability problem areas using the principle of optimal re-use in both code and UX design.
We aim to build up a body of useful resources, for both developers and UX designers, that will help each group create highly reusable solutions to problems that are critical to Drupal users involved with the sitebuilding process.
We believe that rigorous analysis and design for addressing the sitebuilding process can yield a plethora of positive benefits for the entire spectrum of roles from end users to developers. Our intention is to develop a systematic approach to this process that can be utilized by either developers or designers, if they find it is useful to their issues.
Take a look at our SBUI intro video to see why we oriented towards the sitebuilding role.
VIDEO: Introducing the Drupal SiteBuilding Usability Initiative
Where we plan to start (short term goals)
Our immediate aim is to conducting a series of investigations into UX problem areas within the sitebuilding process. Inputs for these investigations will come from a variety of sources, beginning of course with user feedback, but also incorporating recognition of developer realities. While it is important to know what kinds of problems need to be solved, there is no point arriving at solutions that cannot be built.
We do not believe in absolute answers to any UI questions. For that reason, we intend to state the identified problems very clearly and to use this problem definition as a frame of reference through which proposed solutions can be evaluated. Part of the analysis will involve digging deeper into reach general understandings of related problems in order to arrive at solutions that are more likely to be reusable.
We believe that reusable designs will provide the basis for offering useful, actionable recommendations to developers to help them steer towards better, systems-level, architectural solutions.
We are inspired by the great work that has been done to refactor the core architecture for Drupal 8 and want to focus primarily on laying a corresponding foundation for an improved UI system in Drupal 9. We take this seriously and have no illusions about getting results from our investigations into Drupal 8.
There is one exception to this and that pertains to how modal dialogs are brought into core. We believe there is an opportunity to do this robustly in Drupal 8 and that many benefits can come from doing so. That is why we’ve already carried out our first investigation on this subject and have prepared this video that states a case for a comprehensive modal dialog system in Drupal.
VIDEO: Drupal SBUI: Comprehensive Modal Dialogs System in Drupal
Who We Are
Drupal SBUI is being launched by three Drupalers with a combined IT experience of more than 70 years. Together, our backgrounds cover a lot of bases that are useful for this initiative: development (Drupal and otherwise); sitebuilding; Drupal training; UX design; video production and writing. Here’s our coordinates if you want to reach us.
- Thomas Svenson ( tsvenson / @tsvenson)
25+ years in the IT business in everything from distribution and publishing to software and web development from both vendor and client perspectives. Passionate about making tech easy to use. - Michael Keara ( User Advocate / @UserAdvocate)
Software developer and usability expert with over 20 years experience in software design and development, covering both commercial desktop and open source applications. - Doug Vann ( dougvann / @dougvann)
A Drupal developer and trainer whose love for learning and experimenting in Drupal is overshadowed only by his love to teach and evangelize it.
How to Get Engaged/Follow SBUI
If you’d like to keep tuned in to what we’re up to, here’s the places we’ll be hanging out and posting updates to:
- Drupal Home - http://groups.drupal.org/usability
- IRC - #drupal-usability
- Twitter - @DrupalSBUI
- DrupalSBUI on YouTube
- DrupalSBUI Google+ page
How you can help out
If you like being proactive and are passionate about UX – from either the design or development or sitebuilding user point of view – then we’d love to have you join us on this initiative.
We recognize this is a long term effort and part of our aim will be to find ways to increase the efficiency of communication across the design-development boundary. If that sounds important to you then please consider helping with building the structures and processes to do this.
We want to build resources for developers and designers to use in their interaction with each other. This is going to require some research and good analytical thinking. If you’re up for that, we’d love to have you join us.
Are You Going to BADCamp?
Doug and Michael are going there and would love to listen to hear what people have to say about the issues and approaches we’re talking about in SBUI. We’ll be there for most of the four days.
Michael is planning a UX workshop on role-oriented designed as part of the UX summit on Thursday. We’ll try to get BoF together for Saturday too so we can discuss this in person a bit more. Check the chalkboard at the event and we will also send a tweet out on @DrupalSBUI when we have that worked out.
Comments
Awesome effrot
Love this initiative. This initiative is long due and I really appreciate all of you for taking this initiative.
I am very much interested to help this initiative in any way possible.
Welcome
Thanks for your offer to contribute. Great to have you aboard!
Michael Keara
User Interface Systems Architect,
The User Advocate Group
Thank you
This initiative is overdue. This is and has been one of my top priorities over the last year. We need to get together at BAD camp and have a long discussion on this because I am completely on board with what you are doing and I already have several designs that move the ball forward on this. Also I have related initiatives (Like information architecture) that will also aid the goal of your project and which I could use your support.
Looking forward to chatting
Thanks for the support. Very much looking forward to the long chats, especially with beers :)
See you soon.
MK
Michael Keara
User Interface Systems Architect,
The User Advocate Group
IA
Just started these discussions.
http://groups.drupal.org/node/264998
http://groups.drupal.org/node/265003
They relate to our toolbar work and build on concepts you initiated here. Now we have some real data from Dharmensh to support this. (still working with him to annotate).
wonderful initiative
I am open & interested to help this initiative in any possible way.
Sree
count me in ....
Please feel free to count me in!
Surendra Mohan
Drupal Consultant | Architect | Author | Trainer | Blogger
http://www.surendramohan.info/
Wonderful initiative, Doug!
Wonderful initiative, Doug! Please count me in to help in any way I may be of use.
Miguel Hernandez - www.migshouse.com
Founder & CEO - The OpenMindz Group
Writer- Linux Journal & TechZulu
Thanks for your Drupal SBUI support
@dgoutam, @tkoleary, @Sree, @surendramohan & @Techivist:
Thank you so much for showing your support as well as interest to help out. It really means a lot to hear.
We have many ideas about ways to help improve not only the UI when using Drupal, but also many other related, behind the UI, things that will benefit everyone in the community as well as everyone using a site built with Drupal. A big part of Drupal SBUI will be how to collaborate and communicate with many existing groups and initiatives already existing in the community.
It is for that reason we are focusing initially on investigating UX problems, what resources already exists, who want to work with this and how to then best work to improve it.
BADCamp
BADCamp is a great opportunity for us to meet a lot of Drupal users, listen to your ideas and together discuss how to move this forward in an organized and productive way. Doug and Michael already have several meetings booked as well as other activities around UX. If your going there, do try and grab their attention as I know they are eager to here your thoughts and ideas.
They will also, as mentioned in the announcement, try and organize a BoF on Saturday for a round table discussion about this initiative. Make sure to follow Blinky (https://twitter.com/DrupalSBUI) as he will tweet out more about this as soon as we know more.
Next Step
The feedback we get here and from BADCamp will be a great help for us to better understand how to take the next step to get going. We hope to be able to use that to then quickly organize a few projects that you can help working on.
While I know you all want UX and Usability to improve asap, it is also important to understand that this initiative isn't focused on quick hasty fixes. We need real long term improvements that benefits everyone, from core developers to the anonymous site visitors. When that start to happen, Drupal will at the same time be more fun to work with and also much easier to learn and build even more amazing sites with.
So, please have a little patience as we are now taking our first steps to find the balance we need to become a great resource to help Drupal become even better. It will be worth it, I promise!
--
/thomas
T: @tsvenson | S: tsvenson.com
Great initiative
Love the video introduction, and I'm really glad to see this initiative taking place.
I wanted to pipe up about two issues that cause a lot of stumbling blocks to me as a site builder:
d.o.
A huge part of the site building experience actually takes place on drupal.org. I spend a huge amount of time trying to figure out which modules I can use to solve a problem and evaluate themes that might work for a particular project (when there isn't the budget to theme from scratch).
These are both incredibly difficult tasks at times.
One issue is modules with overlapping features. When there are multiple modules that solve similar problems, it's difficult to figure out which is the better module to use. Another issue is that there are very few obvious signals to help determine whether this module is one that's good to use or not. Over time, site builders can learn to look at when the last commits were, how well the module is maintained, etc. Those aren't obvious to new site builders, though. Amazon uses signals like product ratings and product evaluations that help users quickly determine whether or not to purchase a product. I think there is a fear that we want to just make all modules available, with no criticism or praise of modules on drupal.org, but that makes it difficult for site builders to make choices, unless there is a Docs page comparing similar modules.
Another issue is that the themes on Drupal.org don't take advantage of one of Drupal's best features, Taxonomy. Imagine if themes were tagged based on how many columns they allowed, what colors they used, whether there are banner images, whether the design is responsive, etc. And yes, using fivestar to evaluate qualities of the theme, such as aesthetic appeal and code quality.
I'm sure there are more issues like this. My point is that I'd love to see this issue also tackle the fact that d.o. is a crucial part of the site builder experience.
Distributions
Another issue that I don't see discussed often enough are the issues with how distributions work. In theory, distributions are great, because they allow site builders to quickly build up the features of a certain type of site without configuring everything from scratch.
The problem is that the inherent assumption is that most sites only have one primary purpose. If that were true, distributions would be perfect as is. However, in my experience, there are a lot of sites that could really use the features in two or three different distributions.
For example, I run a site for a membership organization that puts on a conference once per year. A conference is one part of what we do, so maybe COD would be useful, but if there were a really good distribution that had great features for working with a membership organization, I'd need to pick which distribution to start from. And if I wanted the features of the other distribution, I'd have to figure out how to reverse-engineer them, and maybe, if I'm lucky, I could port them over with the Features module. That's not an easy task to do.
Or, more importantly, if I have an existing site, but I'd like to add in the features that COD allows, what do I do? Distributions only work with new sites. So do I create a new Drupal site with COD, and then try to figure out how to port over all of my existing content, users and configurations of the rest of the site? Again, very complex.
I think it would be a huge win for site builders if eventually, rather than making a big deal out of distributions, Drupal enabled site builders to add "products" to their site. Product might not be the right name, but the point is that you could add a certain set of individual modules to a site, bundled together (or if a module is already installed, just the modules you need), along with the necessary configurations for those modules to easily set up the sort of features that a distribution provides.
The trick would be if the product uses modules already installed on the site, how to deal with the configuration issue: do the product's configurations override the current site's configurations? Or is there a way to sandbox them, so a certain set of configurations are made in a way that doesn't change the existing site's settings. I'm hoping that the Whiskey initiative might enable something like that to work.
The point is that it needs to be easier to add features to a site without having to start from scratch from a distribution or determine how to install a half-dozen set of modules each with their own configurations. Recipe pages can help with the latter, but an easily-installable solution would be really handy.
Summary
Those are just a couple ideas I have from my experience as a site builder. I'm sure there are a lot of other great ideas out there too. The important thing is that I'm very glad to see that this being made a priority for Drupal's future.
Spot on
Thanks for your informative comment Marc. You are absolutely correct that these are issues that sitebuilders have to deal with on a daily basis.
Its definitely things for SBUI to work on in one, or a few projects. We are currently going over the last bits of reflections after BADCamp and are working on finalising a couple of things. By next week we should be able to present a short term plan to get things going.
I very much like you ideas and the experience you have is exactly what we are looking for.
Looking forward to work with you within SBUI and together help improving these things.
--
/thomas
T: @tsvenson | S: tsvenson.com
Thanks for that input
As someone who loves to do problem solving I find this an inspiring comment because it lays out a lot of very interesting dimensions for investigation. The points you raise are worth re-reading a few times to let it all soak in. Thanks for taking the time to do this.
Michael Keara
User Interface Systems Architect,
The User Advocate Group
Great initiative
As others have said, this is long overdue. I'm so pleased that someone has taken the time to put something together, which has already proven to get some good starting ground. I have 4 years of Drupal site building experience and about 6 years of UX experience. I'm looking forward to hearing the feedback from BADCamp and seeing how I can help. Great work on putting this together!
Danielle Sheffler
Engagement Manager at Acquia
http://www.acquia.com
Trying to get funding for Field UI
I'm trying to get some budget for Field UI improvements to work on http://drupal.org/sandbox/swentel/1824298
Anyone who wants to chip in, please contact me.
Site Builder VS User terminology?
I think I've finally located information on Drupal.Org that would be helpful for people like me. I can't be the only site builder who is not, and does not want to be, a programmer. So if this is finally a resource for people like me I say Halleluiah and please help me locate other resources like this.
Basically what I'd like is to find and work with mentors and occasional consultants who would help me solve problems at the level of a site builder, who could speak my language and would only resort to code after all else fails. So far everyone I have tried to consult with or hire wants to dive into code to solve problems when modules or themes don't behave as expected. I think part of the problem is - there is no recognized role called "Drupal site builder"... Drupal people only seem to recognize developers (programmers) and users (who, in my way of thinking, would be the users of the sites I am developing - not me!). Am I wrong about this?
Ah.. now I've seen your role definition page - bravo. Now if there was just a site builder community I would have hope for the future.
Thanks for you nice words and
Thanks for you nice words and excitement about my community initiative.
I just want to start by clarifying that Drupal SBUI is not about learning to build sites with Drupal. Its actually the other way around, learning about the challenges, issues and other things faced when doing so and then find ways of how to improve both core and contrib projects. Our ambition is to help make Drupal easier to learn, build sites with and even more fun to work with. Not just for sitebuilder, for every role involved in building, maintaining, administrating, contributing to or just visiting.
However, by engaging with Drupal SBUI I'm sure you will learn a lot of very useful concepts and tricks as a nice bonus side-effect. Something you definitely will have use for as a sitebuilder.
I agree that role names can be very confusing. Take "Web developer" as an example. For me it actually says nothing really relevant about what that person does or can offer me.
For me, the Sitebuilder role is simply about configuring features using the UI. Writing code is not part of this role.
In the rolemap in the http://www.tsvenson.com/blog/2012/08/the-drupal-site-building-experience post you refer to, I tried to map out roles and relations as I understand them. maybe it could lay the foundation for the community to build a more detail role definition list from.
--
/thomas
T: @tsvenson | S: tsvenson.com