This is the question I got at many events where I presented about localize.drupal.org. We've just rolled out support for suggestion exports for translators about a month ago to make quality control and management easier, but that does not help people much who are just looking to download what's available.

I've also announced about three months ago that translation downloads were becoming stable and continually generated in a nice pace. However, the usability of those downloads left a lot to be desired. When looking at project pages on the site, you were shown a bland list of links to major Drupal versions the project was compatible with which all led to a long list of filenames on an FTP browser frontend. Also, some files being months old looked shocking given I've told you the downloads are now stable and up to date.

read more

I spent some time reviewing UI design work on Views 3 (And Acquia Gardens "Data pages") UI concepts:

• "Views 3 UX Season is open", February 2010, Yoroy
• "Views 3 UX workflows and ideas, round 1", April 2010, Rasskull
• "View3 UI explorations, part 2", July 2010, Yoroy
• Acquia Gardens "Data Page" concept mockups, Jeff Noyes?
• "More Views 3 concepts", July 2010, Jeff Noyes

NOTE: I have not read all of (or even very much of) the related discussion, so am likely missing important developments.

There are some great "sky-high" ideas in most of these. However I think it's likely that all of them will run into issues as or more significant than the current UI, in that either;

• They will be be too restrictive upon advanced functionality and features and make them difficult or hacky to include in the (in the case of Gardens, that is likely intentional, as advanced features are probably not supported);
• They will have similar types of unforeseen issues to the current UI. Subtle and seemingly minor nuances or even features that actually make a big impact on the UX.

I think this Gardens concept would be particularly dangerous for Views-core, as it is much more like Views One's UI than Views 2, and I expect would have many of the same issues, annoyances and UX problems that Views' One's UI had — especially if it were scaled to the complexity that all of Views 3's features will take it to.

Developing Rasskull's concept

Of all the concepts I think Rasskull's concepts are the most likely to succeed in improving the UX — largely because they are not so radically different to the existing UI. The changes mostly involve just moving displays above the main config area, introducing settings groups as vertical tabs, and moving the "edit area" to the right of the settings table-summaries.

The new settings groups in Rasskull's rev6 are "Views settings", "Data Sources", "Filters, sorting and arguments", "Display settings" and "Overview". Views wants site-builders to build a mental model something like this:

• What data to render?
• Where in Drupal to render it (page, block, feed etc)?
• How to render it (list, map, table etc)?
• How to render each item (full node, teaser, fields)?

Considering that mental model, I think the following could be a better grouping of Views settings (in this order). Sorry for the underscores. GDO breaks the layout without them:

1. General
   1. Overview?
   2. Basic settings
   3. Advanced settings
   4. Page settings
   5. _______________________________________________________________________________________________
2. Data sources
   1. Base table
   2. Relationships
   3. Arguments?
   4. Fields?
   5. _______________________________________________________________________________________________
3. Filters & Sorts
   1. Filters
   2. Dynamic Filters / Arguments?
   3. Sorts?
   4. _______________________________________________________________________________________________
4. Display
   1. Header
   2. Display style
   3. Row style
   4. Empty text
   5. Fields?
   6. Footer
   7. _______________________________________________________________________________________________

Iterating the existing UI instead of exploring a new concept

Putting that whole concept aside, I think there is also a lot of potential that has not been explored with iterations of the current UI — which despite a few unusual/small but greatly-annoying nuances, is actually very good, and has already been through extensive wireframing, review and iteration (as well as implementation!).

As Yoroy puts it;

1. "Too busy! Everything all the time. Provide an easier path into the jungle please."
2. "There's got to be something else we can do for that bottom drawer settings part."
3. "This overriding thing confuses the heck out of me."

Starting from the end, with number 3.; "This overriding thing confuses the heck out of me."

Changing a setting or setting group from "uses default" to "overridden" or back needs to be very explicit and separated from the task of editing a setting. It is not a common task, relatively speaking. It is much more common to edit the setting, or to check it's overridden/default status, than it is to change it.

So for starters, lets lose all of the existing "Override" and "Use default" buttons.

Next, how to determine override-status?: Perhaps instead of using italic or non-italic fonts to show the overridden state (which is terribly vague and unclear), each over-ridable setting or setting group could have a status indicator icon — let's assume a green, yellow or orange "LED" for now;

• Green: The setting does not affect any other displays. It is overriding the default display. Or it is the default display and no other displays inherit from it.
• Orange: The display is inheriting the default setting. Editing the setting will affect other displays.
• Yellow: This display is the default display and other displays will be affected by this setting. (If no other displays use this setting from the default display then the LED for the setting on the default display is green.)

In order to help the site-builder to:

• learn what those LEDs mean,
• how settings can be inherited/overridden across displays, and
• not get terribly confused and frustrated along the way,

we can extend this warning-level LED affordance/metaphor to the edit-area, which can have;

• a larger LED next to the "Update" button,
• a background colour that is respective of the warning-level, and/or
• a status bar/strip that is green/yellow/orange.

The status bar or large LED could contain or be a link (and not a button) to the edit-area form/mode that changes a setting or settings-group from "overridden" to "uses default" or back again. Also, tool tips can aid discovery and help build the mental model of what Views overrides are. These tool tips can be on all LEDs in the settings-tables, and if Rasskull's concepts are pursued even in the vertical tabs summaries.

Moving on to item number 2.; "There's got to be something else we can do for that bottom drawer settings part.".

There is. And it's easy. I think this is simply a matter of making the state-change of the edit-area more obvious:

• Scroll the viewport to it so that the whole edit-area is in the viewport (if it's not already)
• Expand the edit area so it is a few hundred pixels high, and put an overlay with a big throbber over the whole settings-overview area and the edit-area.
• Once the edit-area's DOM has been updated and the overlay removed, a subtle animation like a pale yellow background that fades away or a jQuery fadeIn effect, will continue to draw the user's eye to it.

And finally, the first item from Yoroy's list: "Too busy! Everything all the time. Provide an easier path into the jungle please."

I don't believe this problem is entirely solvable, because Views is a damned-complicated tool no matter what you do with it's UI. The only way to make views easier to get in is to remove advanced features — which is obviously not desirable for views-core. Simple views, Gardens and others can do that.

However, these ideas may help. We can try them out and then further develop or pull them if they don't work;

• Shuffle around the settings-overview tables to be more like my suggestion above for Rasskull's vertical tabs-based concept
• Make some settings-summary tables collapsed by default. This was an idea in one of the above concepts — though I'm skeptical that it simplifies the UI more than it complicates the UI. Nevertheless, we could try it.
• Offer smarter defaults, checks for common mistakes, and easier ways to start building complicated views. E.g.
  • New views could always start with a page display
  • New node views could always include a node=published filter
  • Views could warn you when a filters-group does not have a node=published filter
  • The create-view wizard could introduce an optional step to create common and simple filters quickly, such as by node type or term.
  • Instead of exposing default views, contrib modules could offer "templates" which can be used to get started quickly with complex views that, for example have convoluted and difficult-to-reproduce relationships and/or arguments. E.g.
    • Related nodes by term: node->term->node
    • Other user's flagged nodes
    • "My" flagged users (aka "My Friends")
    • Nodequeues
    • _______________________________________________________________________________________________

Usability

At the recent & awesome DrupalCon Copenhagan we had two Birds of a Feather meetings regarding what can be done to involve more designers in the Drupal project.

Four users

• Zach is a module developer who wants his module's UI to look good, have designer-friendly markup, and follow UI best practices.
• Eric is a print designer with no interest in the web. He is obliged to work with a new CMS for his upcoming project.
• Morten is a themer. He has extensive knowledge about the theming layer and does advanced theming and alterations of markup, content and contexts.
• Sarah is a Web designer. She has been working in Drupal for a little while. She has a basic understanding of Drupal theming, but her primary skills are design and HTML/CSS skills. We want:
  • to get her included in the Drupal community (paves the way for interesting and experimental design from a non-Web experience in terms of design).
  • to not scare her off by jargon and code-y language.

High-level goals summary:

"Help me learn how to theme"

• Get Drupal up and running
• Modifying a theme
• Building on a base theme
• Build a theme from scratch
• Guidelines for Core and Contrib contributions: html and css standards

"Show me what can be done"

• Site showcases
• Contrib theme reviews
• Base theme comparisons
• Theme system docs

"How can I help/contribute?"

• Why you should contribute
• Docs
• Review issues
• Themes as Features?
• Skinr snippets?
• Icon library?

"Our studio is (considering) switching over to Drupal for our online projects. Now…"

All:

• Show me examples of well-done design implementations, succes stories.

Beginner:

• What is the easiest way to test-drive this Drupal thing?
• What is the recommended approach for getting my PSD turned into a working theme?
• What are the good themes to learn from? Where do I find these?

Intermediate:

• Ok, great. Now how do I build a theme from scratch?
• OMG! Ugly HTML! Can I change the output? How? Where?

Advanced:

• This Drupal thing rocks after all! Amazing that this is all volunteer work. I'd like to help and give something back as well. Why and how do I do that?

Possible Intentions

• Connecting developers and designers in a way where both parties benefit.
• Opening up the community to people like Sarah who otherwise have difficulty finding of way into the Drupal community
• Documentation/translation/guidelines in the Handbook (theming documentation is hard to find, and it’s explained in developer-speak)
• Create a system for Designers in parallel with ‘Commit’ for Developers
• Written-up proposals
• ‘Designers lounge is right next to the Developers lounge’
• Maybe do design/UI/UX sprints at camps and Drupalcons — make a positive effort to contribute to the community
• Drupal distro for designers (blog maybe?)
• it will help improve the UX of certain key modules
• give them a base theme that looks good
• simplify the initial experience so they can realize that Drupal can give them so much more
• what does a base theme need to do?
• make Drupal dor designers not die!

Attendees

• Marek Sotak; @sotak
• miro; @smiro2000
• Candie (CandieBandit); @candiebandit; candiebandit on Facebook
• Edward (eoriordan); @edwardoriordan
• Jesper Wøldiche (woeldiche) @woeldiche
• Derek Dunagan (drkdn; dude w/ septum ring)
• Conr Cahill
• Jozef Toth (mogdesign; @jojototh @drupaldesigners; drupaldesigners.org
• Thomas Moseler (eigentor)

Aegir example Design For Drupal

TagsDrupal Planet

It’s by sharing knowledge with others that the Drupal community continues to grow and flourish. In that spirit, DrupalCon Chicago will be offering pre-conference training courses and workshops to attendees interested in gaining additional hands-on knowledge on a variety of topics related to Web and Drupal development. We are looking for talented, professional trainers who can share their knowledge at pre-conference training courses and workshops.

These courses will take place on March 7, 2011, before the main conference begins and will be held in the classroom facilities of the University of Chicago’s Gleacher Center, located steps from the conference venue. We are looking for sessions and workshops that touch on all aspects of Web development, from Drupal site-building, module development, user experience design, and beyond.

read more

At the recent & awesome DrupalCon Copenhagan we had two Birds of a Feather meetings (where like minded people meet to have an an informal discuss) regarding what can be done to involve more designers in the Drupal project.

To help aid these discussions we started from the very beginning and created 4 personas. There personas were intended to represent the various types of people who are potentially frustrated with the state of design in Drupal.

Personas

• Sarah is a web-designer. She has been working in Drupal for a little while. She has a basic understanding of Drupal themeing but her primary skills are design and HTML/CSS skills.
• Eric is a print designer with no interest in the web. He is obliged to work with a new CMS for his upcoming project.
• Morten is a themer. He has extensive knowledge about the theming layer and does advanced theming and alterations of markup, content and contexts.
• Zach is a module developer who wants his module's ui to look good, have designer friendly markup, and follow ui best practices.

So what & where next?

These personas came out of a collaborative Google doc (http://bit.ly/asS6uQ). The doc also contains a list of suggestions about what we can do to help these four persona.
I believe the next step is tidying up the doc slightly and creating a space where we can list the different things we can do to help each of these personas.
Essentially creating a list of tasks that need doing and then dividing them up based on their time scales. So the question is: *where do we place this list?*
I am perfectly happy to create something but before I do I would love some ideas. I would also love some feedback about the idea in general.

Design For Drupal

Three days ago on the 27th of August, Drupal.org's localization service, localize.drupal.org held its one year anniversary. It is worth a look back and a look forward to understand how far we came and what kind of tasks are ahead of us still.

The new web based user interface for Drupal localization came to unseat the usual tools used to translate Drupal itself, and its modules and themes. Over 30 teams joined the first two months, and most others followed later. The site now hosts over 70 language teams and numerous are in the queue discussing best ways they can leverage our toolset.

If you look through http://localize.drupal.org/news, we kept improving our performance, make our user interfaces simpler, give team maintainers more control over their teams, etc. We flip-flopped from backend and bugfix updates to user interface improvements and new features. We were the second site on drupal.org to deploy the new redesigned theme and therefore serve as a good test case for how it works.

read more

I presented on my experience doing UX work in the Drupal community: the challenges and opportunities we have towards creating a more richer design community.

Watch original video at MIT TechTV

Taking place in the beautiful MIT Stata Center I truly enjoyed sharing my experiences being in this vibrant community, I feel the discussion that followed from my presentation is the most interesting part.

I feel that it's important to articulate the actual problems well. Drupal has a growing need for design in everything we do, and this will become more and more apparent. I hope to present more often on this topic, because I feel attracting new designers will be crucial in this stage.

On a different note, I have joined User Intelligence running an internship as User Experience Consultant till the end of this year. Exciting stuff!

Hagen Graf did an excellent live usability test at the unconference immediately before DrupalCon Copenhagen. He's a a tech writer well versed in all three of Joomla, Wordpress and Drupal, so he was able to draw out the strength and weaknesses of getting started with each platform.

Below is a cleanup of the notes I took during the live demo. Sorry they're a bit scrappy and not very even in tone! They're not perfect, but I think what Hagen did serves as an interesting demonstration of how, while no one CMS gets everything right for the prospective new user, we can fairly easily examine Drupal in the context of a non-expert's voyage of discovery, and highlight a lot of basic usability stumbling blocks on the way.

Why should this matter?

You can pick and choose your metrics, but Hagen showed us Google trends for the three CMSes. Drupal and Joomla have had a gentle downturn, while W is pretty much flatlined. Why that's happening nobody knows, but it's worth worrying about usability if there are obvious low-hanging fruit. I think: Hagen was pretty cagey about what goal we were trying to achieve!

Which should the user choose?

He started off by showing a handful of sites in quick succession, and invited us to work out which was using which CMS. Katy Perry, Atlantic Southeast Airlines, Schweizer Illustrierte... It was hard to tell. Someone shouted out "if you showed me the HTML source I could tell you!" but there wasn't a lot between the sites to make a user pick any framework on the basis of their stumbling across any of them.

Obtaining the CMS

He then followed the journey of an imaginary user to the three promotional websites for each framework. Wordpress and Joomla had clear ways of funnelling the curious visitor into "showcasing" sections, which show off the best that each framework has to offer. In comparison there was no obvious showcasing for Drupal.

He moved on to trying to download Drupal, and very quickly got lost in the list of thousands of modules. This all seemed pretty scary from the user's perspective.

Side note: SAAS

Wordpress has really easy-to-find software services on wordpress.com. Drupal's is somewhat harder for the new visitor to find, on drupalgardens.com . Joomla has no equivalent offering.

A major task

The rest of the demo was of a specific user journey on all three:

• Install the system and get into the admin interface
• Create content and upload an image associated with it
• Have the content look OK

Installation

Joomla

Smooth installation, will even create db if the user you give it has permissions. A slight glitch in usability: you have to remove an "installation directory." What does that mean? It also provides some sample data.

Wordpress

Briefly unfriendly. it won't create db for you, and will explode instead. If you now go and create it, what now? There's no back button. When you're done, you start automatically with a sample blogpost and page.

Drupal

Well, I don't know what an install profile is, so whatever. Click default. I can... add several databases? Whatever. But: if the database doesn't exist, there's a big, ugly kaboom. With no obvious explanation. When you're done no sample content, but D7 does give you quick routes to add content.

Create content

Joomla

Wow, that's a lot of fields. Role-based permissions are on the article itself, which is quite nice: but will that scale on big sites with lots of roles? You can't put the article on a menu here. If you're a beginner, menu manager will basically put you off. Also, you can't turn off print/send-to-friend - you can't turn off. Media directory looks a bit like iMCE. Quite fiddly but functional.

Wordpress

The media gallery is right there. And it works

Drupal

Very complicated to set up a field for images. It's nicely configurable but the switches are hard to find. And if you then upload a big image.... Wow, that's a big image. How do I change its display? Display fields on the content type? well, people can't always find that.

Interface to the nuts and bolts

Hagen made the point that if the client wants the image floated, you can't really do that without starting to edit the templates: which you can't do in the browser. Wordpress lets you do that in the browser. Is that the right thing to do? Well, that's a long debate. But does the end user care? Will end users choose Wordpress because it does the "wrong thing"?

In Drupal 7, it's possible to install modules through the interface, even via URL. But when you try to do something like e.g. the WYSIWYG module - how do you get the third party editor? Answer: you can't. You have to go back to the filesystem, or back to FTP.

Wordpress plugins are all really nice e.g. upgrade akismet, or find new plugins... Joomla has this massive confusion of modules, plugins and components, and is just not there.

How can we improve Drupal to get this audience?

Hagen said (I paraphrase): "Agencies don't always know how to incrementally improve a site. They change incrementally but they're not improving it. Six months later it's a mess. We need a core like Wordpress. It just works. Too many agencies and products and programming. If you come from the outside you think, wow, it's like Java!"

Someone started telling him: "But if you extend..." He replied that: "Well, everything can be solved with ten modules and some tweaking and some code... But that's not the same as audience-ready. Joomla templates are strongly MVC, so customizing is easier. But Joomla has no clear competitor for views. Wordpress has fields on a per-article basis, and you can combine that with a plugin. Field-to-field dependence in Drupal is possible but hard. Not necessarily hard for a developer to program, but hard for a user to set up.

Conclusion

Hagen tried to make us see Drupal's installation procedure (alongside that of two "competitors") through a fresh pair of eyes. We're too close to Drupal to see all of its flaws, but I think this was pretty illuminating.

Generally Drupal's zero-to-image startup is less fun than you'd think, if you don't know your way around. There are lots of configuration options, but it can be frustrating to find. It's certainly not "media-ready" out of the box. The only solution to this is more user testing, more critical examination of the process, and more willingness to learn from our competitors and willingness to fix things even when the bug actually "worksforme". By examining what other CMSes do then we should be able to make Drupal's user experience the best of all of them.

Usability

We're entering a new era of the web. To the ignorant masses, this transition will go largely unnoticed; they'll enjoy increased usability and convenience, with more robust functionality and more relevant data at hand. And they'll mostly just take it for granted.

However, for web designers, front-end developers and data system programmers, we have a lot of work to do.

Why HTML5?

Why indeed? As someone who's worked almost exclusively with Drupal since 2004, my nose has been pretty much in xhtml 1.1. Back then, moving to xhtml took some learning and patience on my part, having played with basic HTML since 1995. Now xhtml feels like the familiar friend and HTML the ugly cousin.

But then I started really looking at HTML5. And the more I am learning about it, the more I am appreciating how HTML5 looks to be a real game-changer.

DOMinate the web

Most of the buzz you see online about HTML5 focuses on the particulars — with the plurality of coverage over how HTML5's media tags stand to push most uses of Flash out to pasture. And that's certainly big.

read more

Omnigraffle stencils #ui great prog for diagramming interfaces, http://bit.ly/2J0JBU perfect #ux wow #d7ux

Omnigraffle stencils #ui great prog for diagramming interfaces, http://bit.ly/2J0JBU perfect #ux wow #d7ux

Omnigraffle stencils #ui great prog for diagramming interfaces, http://bit.ly/2J0JBU perfect #ux wow #d7ux

Chris from LevelTen recently posted a great article on Drupal modules for improved usability. However, these focused on the administrative side of the website, not end users. So here is our own list of modules for the front end of your site!

You do not want your Drupal site’s users to get lost in a myriad of long forms, fieldsets, page redirects, and confusing tagging. You want to do everything you can to make navigating your site and completing frequent routine tasks as painless as possible for the end user. This will keep them calm and give them warm fuzzies to know that they can use your Drupal site with ease without having to pop a Valium just to endure the overwhelming experience of encountering your site.

read more

Start:  2010-08-25 17:15 - 18:00 Europe/Copenhagen User group meeting

Community products usable out of the box : How is Drupal able to "compete"?
BrainStorming session Monday 3:00 to 4:00 pm Copenhagen time, Register at http://groups.drupal.org/node/88459)

Drupal has now at least two community products usable out of the box. http://commons.acquia.com & http://openatrium.com
(Edit 20100822) http://drupal.org/project/voicebox targeting targets community media
+ facebook like feature http://sndemo.dev3.webenabled.net/node/1

There is a need to see how those projects compare and are able to "compete" with non-Drupal products.

The output of this brainstorming session could be a list of features based on a competition analysis focused on the most successful of each targeted audience :
-With enterprises in mind we could focus on http://sharepoint.microsoft.com/ & in SaaS mode http://www.jivesoftware.com
-With a general audience in mind http://buddypress.org or in SaaS mode http://ning.com.

That way we may be able to coordinate our efforts and see what our weaknesses and strengths are.

This opening informal session is meand to complement the sessions of the official shedule :
http://cph2010.drupal.org/sessions/acquia-sponsored-session : accelerating drupal adoption through SaaS, distros and more
http://cph2010.drupal.org/sessions/15-modules-help-you-build-community-w...

BOF sessions :
http://cph2010.drupal.org/sessions/drupal-commons-social-business-software
http://cph2010.drupal.org/sessions/federated-social-web-and-drupal

Based on previous discussions on GDO

http://groups.drupal.org/node/53268
http://groups.drupal.org/node/45468

There are lot of participants who could give a valuable input outside of the conference. We will use Ustream and I schedule it at 3PM European time / 9AM in the US.

Open Atrium

Fri, Aug 20, 2010 by David Tiede

Just a quick tip on improving the user experience of your site. By default, browsers are smart enough to figure out if parts of the page exceed the visible boundaries of the browsers' window. On the other hand, when you're viewing page that you can interact with (be it expanding a block of text, or loading a new tab via AJAX), often times the page's boundaries will change (i.e. the height of the page will increase/decrease) and the scrollbars will be added/removed as a result or more/less visible content.

Although this default behaviour is fine for most static sites, it starts to take away from the user experience when the page shifts left 20px and right 20px each time a scrollbar is added and removed, respectively. It's difficult for the end user to focus on what content actually changed versus what stayed the same. You'll notice a more seamless experience when switching tabs, and dynamically loading content.

By simply adding a CSS rule to the html (or body) tag, you can eliminate this so-called page jitter that happens each time the content is modified on the page.

In your main .css file, add the following code

html {
overflow-y: scroll;
}

I’ll be the first to admit that I’m no usability expert, but I do know pretty quickly when a feature on a site is hard, tedious or confusing. In that same vein I’m a sucker for when things make my life easier! I can do the same amount of work in less time to get to doing the things I enjoy; which is why I love these five easy Drupal usability modules. Setup on all of them is a snap and when you’re done you’ll actually have more free time, and we all need more of that.

read more

Apologies in advance for this crossposting to 11 groups. I recently started an issue to help us get to know each other better: Add field for "Memberships in Associations, Societies, and Other Professional Organizations" to User Profile. The initial response was, "Don't see why not, but let's hear more support before we do." So this is an appeal to read the issue and consider giving it your support.

This is especially important in some of the more specialized groups — do I answer this question as if I'm talking to an SEO expert, or does this person need to know the background that they skipped over? To a great extent, being able to see their professional affiliations will answer that for me.

Another way it could help is to identify specific Drupalists to target for a BOF at any upcoming event. As a hypothetical example, maybe someone is not in the Design and Information Architecture group, but is in the IxDA. Shouldn't we be sure they know about any Design BOF that is being planned?

This new field would appear under "Work" and would be at least a text field so you could enter any membership you have that you feel is significant to your online activities in general or your activities with Drupal in particular. Ideally, the field would accept html, as does "Companies worked for," so you could link to the website of each group or association you list.

As with any other fields in the profile, no one would be compelled to complete this one. It would simply be available to anyone who felt that it was useful to share this information with others in the Drupal community.

Please take a few seconds to give your support to Add field for "Memberships in Associations, Societies, and Other Professional Organizations" to User Profile.

Drupal for State and Federal Agencies / Government

RT @Schaffner_Comm: HTML5-Drupal7-Theme: 'Boron' on http://drupal.org/project/boron/! \#html5 #drupal7 #d7 #d7ux #d7dev #boron #theme

HTML5-Drupal7-Theme: 'Boron' on http://drupal.org/project/boron/! \#html5 #drupal7 #d7 #d7ux #d7dev #boron #theme:... http://bit.ly/bLMlK6

HTML5-Drupal7-Theme: 'Boron' on http://drupal.org/project/boron/! \#html5 #drupal7 #d7 #d7ux #d7dev #boron #theme