SEO Expert Blog

Goal: provide a mechanism for community to suggest ideas and evaluate community support of proposed ideas via voting. Similar projects: brainstorm.ubuntu.com At first stage idea gathering will be limited to Drupal.org project only, with possibility to add other projects if necessary. Purpose Tool aims to be a centralized place for all the brainstorming around improvements to Drupal.org. Currently idea/suggestions are scattered around various issue queues, groups, wiki pages etc, making it almost impossible to follow everything and see "big picture" of features in demand. Tool will be able to show: Ideas that have broad community support, which also: a. have ready solutions provided by community (read - someone wrote the code already and it just needs deployment) (example - Documentation team changes to doc pages) b. do not have ready solutions provided by community (read - everyone wants the feature but noone has time/wants to code). (example - "kill +1 comments" initiative, topic pages) Such ideas might attract people who want to contribute to d.o, but do not know where to start, or future d.o web dev team could possibly take care of them. Ideas which do not have broad community support. Process Logged in users (supposedly d.o users via Bakery) will have an ability to post Ideas. Each idea will have: - Project to which it's related (At first stage only 1 project - drupal.org) - Title - Description - Related issues/ g.d.o posts - Tags - Status: Active, Closed as duplicate, In work, Needs deployment, Implemented etc. - Comments - Solutions - This will require separate discussion on will it be special type of comment, can people vote on solutions etc. (will post separate discussion later) The simple process is to have ideas.drupal.org open for adding ideas and voting all the time. Another suggestion is to keep it open for adding ideas and comments, but open for voting only for certain periods of time, when there is a need to get up-to-date opinion of community on the state of things. When idea gets added to idea pool it has status "Active". When number of people steps up to work on something - idea status changes to "In work" and information is provided in idea description about the coordinators of efforts, place where work is being done, how to get involved etc. When the solution is ready, it is posted back to idea and status changes to "Needs deployment". After solution was deployed on d.o - idea gets status "Implemented". This tool will at any given time be able to give an overview of all the work being done by various community members on d.o improvements. It could be used by future d.o web dev team to help them set priorities when planning. Also it hopefully could make process of developing for d.o more transparent and attractive for prospective contributors as it will show that anyone can work on d.o improvements and that ready solutions do get deployed. As a last note to this pretty long text, I am willing to build this site if idea has at least little support. Prairie Initiative

---

Leading Drupal's migration from CVS to Git made something eminently clear to me (and eliza411, the migration's PM): there's a lot that's broken about how we manage, maintain, and improve drupal.org (and its subsites). Since then, I've been gradually chatting up more and more people with the idea that we could build a structured, participatory model for updating and adding new features to drupal.org. And that if we do it right, it could become a best-practice model for (Drupal) site management (open, participatory) workflows. There's a nice, articulate big picture summary & justification for this project that eliza411 is currently writing up, which'll be the unifying thing we rally behind. In the meantime, though, the document she and I drew up over the summer is still more-or-less accurate. Maybe the biggest scope difference is that we think this should extend beyond just d.o - if we do this, it should really be done for *.d.o. Bottom line, I've now talked about this idea with way too much to keep it under wraps any longer. So I'm posting this brief overview in order to kickstart public discussion and progress. Which, by the way, I'm hoping will go like this: Once eliza411 has gotten the new-and-improved overview written, we can fight about the broad goals and scope there. We collectively generate a backlog of tasks that accomplishing the full scope will require. We gradually morph this backlog into a collaborative scope of work document. We have regular IRC meetings to help hash things out. I've started #drupal-devops for this purpose as I can't think of another channel it belongs in, though if folks think #drupal-infrastructure is fine, that'll work. I'll keep devops open since I think it's a worthwhile channel for us to have, anyway :) We pair the scope of work with the overview + some other goodies, turning it into a proposal that we can bring to the DA for funding, and/or Kickstarter or this new http://www.drupalkata.com/community-initiatives/ idea. That collaborative backlog generation should take place in this shared google spreadsheet. If you want to help out, give me a ping in IRC and I'll grant you some perms to edit the doc. Actually, I'll give you access to the whole collection, we're putting all the docs related to this project in there. Please note, however, that everything in that backlog will eventually be translated to issues on drupal.org. That spreadsheet is merely a convenience for collaborative brainstorming right now. Basically, we're talking about building a deployment pipeline, per the ideas discussed in the very hot-topic devops book, Continuous Delivery. For anyone seriously interested in this, I STRONGLY encourage you to read the sample chapter they've made available online. There are some things that I think don't quite fit for our requirements, but on the whole it's an excellent breakdown of the value to be gained here. That spreadsheet has already been divided into the six work areas that Melissa and I believe adequately encapsulate the overall goals of the project. Bazaar -> Git: drupal.org infrastructure primarily uses bzr at the moment. We would shift over to git in order to keep volunteers from having to learn yet another skill, especially one that is unlikely to transfer to new Drupal projects. This area of work also entails choosing a hosting solution for our Git repos, as well as a branching strategy/rules. Puppetize Prod: Pervasive use of configuration management is essential to replicability. Puppet is the system the OSL has chosen, and we are following suit. So one of the first steps is necessarily rolling our existing infrastructure over into puppet. Sanitization: While we want to make this process as public as possible, there are some limits. Some data (e.g., user emails), some settings (e.g., settings.local.php) and some code (e.g., Bluecheese...maybe) should not leave the drupal.org servers. However, some components require some normally sanitized data to function (e.g., Git integration requires emails for commit/user mapping). This work area is about figuring out where these limits are, and how we accommodate them. Environments: The meat-and-potatoes of this whole project: provisioning new, full-stack VM clusters for development, testing, or staging, and either locally (on a developer's own machine) or centrally/shared (on drupal.org-owned servers). Vagrant (so Virtualbox) will be used for the local instances; central is TBD. We'll need to keep an eye on keeping the builds componentialized, otherwise a full-stack local environment with all *d.o properties could mean >15G of local space. CI and QA: Drupal.org has no integration tests, regression tests, etc. This lack of QA is a huge reason (at least for Git) why we don't see more progress. This area of work is about building out a real suite of tests for all *d.o sites (that participate) and building a real CI process using those suites. Process: The other areas of work are relatively separate work blocs; this is about putting them together so it all runs like a finely tuned machine. How & when code moves through dev/qa/stage/prod; how new folks get set up with environments; this sorta thing. The goal is to create a clear process with good answers to the major user stories, and clear expectations around how and when different things happen within infra. eliza411 and I have tried to provide a good structure for this planning process, but we're figuring this out as we go along. So if folks have any suggestions about techniques for collaboratively defining & scoping an overhaul like this, they'd be welcome - though we're going to play a balancing act against things that would derail this overall effort. Paying for the plumbing

---

I know what it feels like to have your hard work critiqued, piles of issues to solve and to deal with some of the hardest discussions and posts we can have. I know the many hours spent, sacrificing time with our loved ones, time without sleep or the so many other things we give up to do our part. We must remember that we are all a team, that many of us put the project before ourselves, our egos, our profits and even our opinions. But most of all I wish to express a BIG THANK YOU to the Module Developers, Core Contributors, G.D.O. and D.O. teams, Documents, Security Team and countless other people who often never get mentioned or talked about. Lets just step back and look at all we have accomplished. Working on one the best content management system in the world. Bringing a system that was a simple forum into one of the few systems that run the web! You all rock, and don't forget it. I know that I can't possibly thank every individual who has helped Me these past few weeks. Filling issue queues with Thank You's would probably be get old fast. So here it is. Now lets kick those negative posts off the top of "whats hot" or "topic of the week" or what ever the heck its called and put something of real value up! Diversity and Outreach

---

The Prairie Initiative – Update View more presentations from leisa reichelt I had the opportunity to attend Drupalcon London this week and to talk some more about the Prairie Initiative – what is is, our goals, and the progress we’ve made so far. Unfortunately the audio in the session recording was very poor, so here’s an outline of what I presented. Recently I came across a ‘register’ page on a Drupal site that was obviously Drupal (in a bad way). I thought – I wonder what it would be like for people who don’t know anyone in the Drupal community to come to Drupal.org and try to find how they can contribute their time, skills and experience to fixing the design of that page. Try this exercise – go to Drupal.org homepage and log out. Now imagine you’re here looking to help out in whatever your area of expertise is (if you can’t think of anything, just pretend you want to help fix the usability and layout of that register form). Where would you go? If you headed into Support and Community (which is probably the most sensible option) you’re hit with walls of text, no keywords that confirm that we want people like you and where you should go. Very little sign of a community at all, basically just a list of channels. It’s less than inspiring and a little intimidating. IRC is not a solution – it scales badly, it’s intimidating and unfriendly if you’re new and unknown, and for a great swathe of us, it’s very unfamiliar. Groups – try going there and logging out. This is also a pretty poor introduction to the community for newcomers. Forums are also pretty haphazard and not really a recommended entry point. If you decide to ‘register’ (for what, it’s not really clear) you enter a process that is riddled with small but unrelenting errors or bad experiences – from the lack of client side validation on the forms, to the ‘access denied’ heading once you’ve completed the form successfully, to the personality free email you receive (and the fact that we have even designed the sign up process this way – making the user do the work to reduce the spam on Drupal.org presumably) Having completed the registration process, you’re left pretty much stranded on the final page (which announces that it’s unsubscribed you from a mailing list you’ve never heard of) – the dashboard for newbies doesn’t take advantage of a great opportunity to help you get started. Fortunately, in the journey that I was exploring – search does work, and if you make your way to the Usability Group page (which has been pretty well thought out and structured to be newbie friendly), you’re set – you can actually find some likeminded people and start finding your feet in the community. These are all little things – things that could reasonably easily be fixed. And some might say that if you can’t handle this then you’re probably no use to us anyway – Drupal gets a whole lots hairier than this! And that’s a fair point – afterall, if you do make it through the onboarding experience, sooner or later you’ll meet the issue queue….*gulp* The onboarding experience into the Drupal community on Drupal.org is a bit of a car wreck. Sure, it’s just a series of little things that could be relatively easily fixed – that’s not the point. The point is that we either have never bothered to check that the sign up / onboarding experience is any good, or it’s not high on our priority list. No one owns this job. This tells us some interesting things about the Drupal community and sends some messages about what we value: We don’t really value our newcomers or care about the experience that new people coming to join our community and contribute have when the try to get involved. We don’t really care about the quality of the products we create and the spaces we reside in (there’s no broken windows policy on Drupal.org), we don’t take pride in our flagship(?) website. People who do manage to get involved using this process are to be admired for their determination! There is an alternative onboarding experience – person to person mentoring and hand holding, particularly for those who have been hired by a Drupal shop or are working in an organisation that is adopting Drupal. This is a good process – perhaps it’s the one we really care about? Perhaps we don’t really want people to randomly stumble into the community? Perhaps – these are all questions to think about… We need to work out what our position on all of this is. What kind of people do we want to have in our community? How do we want to ‘recruit’ them – do we want random people coming to the community from our website? (hobbyists etc?) What kind of an experience do we want it to be to sign up to be a part of Drupal? What kind of experience do we want to be to be an active contributor to Drupal? How important is this to us? How much do we care? It’s ok if we decide we don’t care about it so much. The right answer isn’t necessarily ‘the user experience must be fantastic’ but we should stop paying lip service and actually not doing anything about it, and not committing any resources to it. We need a vision for what we want the experience of Drupal.org for new and long term contributors to be like. Backcasting is a great exercise that helps us work out what we’re aiming for and then a roadmap/strategy to work towards that outcome. For me, I think this is important. I believe that the way our spaces are designed is very influential on the way that we behave within them. Drupal the community and Drupal.org are both pretty good at tactical problem solving, but both pretty rubbish at defining and agreeing and acting on larger strategies. This is what the Prairie Initiative is interested in – ways that we can design social spaces on Drupal.org that are more conducive to giving new contributors a better onboarding experience and that makes it a better, more productive environment for longer term contributors. The Prairie Initiative is not a project. Rather, it is a family of projects that share a connection to a common set of goals. The goals of the Prairie Initiative projects are: to improve the collaboration tools on Drupal.org so that we can do more and work better together and make Drupal better, faster; and to grow the pool of contributors by making Drupal.org a better and easier place to become a contributor – to make it less intimidating to people who want to get started contributing. Some of the projects within Prairie that we are moving forward with at the moment include: Topic page – a place where activity from across the Drupal network can be aggregated and people interested in this topic can ‘follow’ the topic. This allows people to self identify their expertise, people to find likeminded peers in the community, people to find mentors, people can more easily keep up with activity on Drupal.org related to their topic. Profile page – a better designed profile page allowing us to share our expertise and experience and interests and activities within and without of Drupal more easily, and a way to make the reputation system known to ‘insiders’ accessible to those who are new and as yet not well connected to the community. Issue Queue - exploring ways that we can change the issue page so that it lets us work more effectively together. Notifications – exploring how we can make it easier to keep up with activity on Drupal.org you’ll probably be interested in without requiring you to be on IRC, have people ping you links, or be scouring issue queues and groups endlessly to keep track. I’ve been trying to do as much of this as I can in my spare time but – realistically – I’m not a great candidate to help lead this project. It really needs someone who works in a Drupal company and who gets some ‘gardening time’ (or equivalent) to work on community work without having to sacrifice income or time with their kids. Having asked around a little to see if there might a chance of getting a little financial support so that I can work on this in place of client work, it seems clear that Prairie is currently not a very appealing investment. I probably need to work on my pitch, I guess, but that’s pretty demotivating. Especially when you not only need someone like me doing cat herding, ‘product management’ and some UX work, but we really also need a tech lead (someone like this who, unfortunately, is much the same as me in terms of having no gardening time).If you’ve got time and inclination to take this on, step up. Otherwise, regretfully, it’s likely Prairie will flounder, as it has for the past month or so after an initial cracking start (this is entirely my fault and not for want of people willing to contribute their time). I know this sounds like a huge critique of the work that was done by the redesign team and by those who continue to work on Drupal.org – please know that there are many, many things that need working on and people like Neil Drumm and Lisa Rex and others are doing great work that goes largely unrecognised and unthanked. This is absolutely NOT a criticism of their work and I’d like to thank them and the others who are working with them for continuing to incrementally improve Drupal.org. We might have re-THEMED the entire site but there was a LOT that never had the chance to be reDESIGNED. These are very different things. We still have much work ahead of us – if we decide we care, enough.

---

I changed the name of this group to "Drupal Association improvements to Drupal.org" (after clearing it with the existing group owners). The Redesign is over but the Drupal Association will continue to promote and assist with improvements to Drupal.org. The D.A. and the community can use this group to discuss D.A. funded involvement/improvements to Drupal.org. Purely community-driven improvements should be discussed in it's own group, Drupal.org Improvements. Drupal Association improvements to Drupal.org

---

If you’ve spent any time hiring User Experience Designers chances are that they’ve shown you some examples of their work in a portfolio with the following disclaimer: don’t look at the website though, it’s terrible. We’re currently operating with this tacit agreement that you can do great design ‘in theory’ but that it’s not our fault if that design never makes it to market. Or if it gets totally transformed so that it’s unrecognisable by the time it goes live. Can we really go on like this? Doesn’t it make you question your own existence? Sure, there are a LOT of things that come into play between the time you present your awesome design and when the code hits the live server, but it seems to me that, as UXers and designers, we’re largely stepping away from the plate to wash our hands clean of responsibility for what happens. (How’d you like that mixed metaphor?) I think we might be letting ourselves off a little too lightly and, for myself, I’m going to take starting a lot more personal responsibility for whether and how much of my design sees the light of day by thinking more about: the nature of my engagement with clients and the shape of my projects - as a freelancer, the way that I engage with clients can vary a lot from client to client. I’m going to think more about how I can design engagements that maximise the chances of good design going live (this is part of the reason I recently kicked off UX Tuesdays) communicating design and user experience strategy – are you spending enough time on communicating your design to the project stakeholders? Are you giving them tools that they can use to help make good decisions as they move through the implementation process (where, let’s face it, some of the most important design decisions are made in the absence of a designer). Do your clients/managers understand the implications of the decisions they’re making on the integrity of the user experience? Quick tip: a functional spec does not tick this box. staying in the debate – are you still around when your design is being taken apart? are you engaging in a discussion to help save your design work? It’s easy to swan off like a princess mumbling under your breath about people who don’t appreciate good design work when they see it. Are you helping them (sometimes with a little force) to learn to appreciate it? making sure you’re designing things that can be implemented – it’s all well and good to design a thing of beauty but does the team have the resources to bring it to life? Have you made something that’s beyond their current capability? If so, then, how good is your design really? From this point forward I’m taking personal responsibility for the design that goes live, no matter how far it is from the documents I might show you from my portfolio. In the Drupal community they say ‘talk is silver, code is gold‘. Let’s make a new UX motto: ‘portfolios are silver, live design is gold‘. Let’s own the work that goes live, understand and explain why it is as it is, and work on the skills we need to make sure more good design actually makes it over the line. Otherwise, what’s the point? Are you in?

---

I’m sure that many of you will have heard about the very worthy Alpha.gov.uk project, the first prototype of which was released earlier this month. If you’re a user experience practitioner, this should particularly interesting to you. By way of a quick background, the AlphaGov project was formed in response to findings from a report by Martha Lane Fox, Revolution not Evolution into Government online services and opportunities to improve. (As a tangent, I’d love to see her in a cagefight with Lou ‘The redesign must die‘ Rosenfeld) In this report she recommended the introduction of “a service culture, putting the needs of citizens ahead of those of departments” The AlphaGov project responded, setting out two overarching objectives: To test, in public, a prototype of a new, single UK Government website. To design & build a UK Government website using open, agile, multi-disciplinary product development techniques and technologies, shaped by an obsession with meeting user needs. See. It doesn’t get more UX-interesting than that right? It reminds me quite a bit of the D7UX project I worked on with Mark Boulton and the Drupal community, so I’ve been following it’s progress with a keen interest. Now, go have a play with the prototype and see what you think. I’m actually not going to comment on the UX of the prototype today, partly because it’s actually quite difficult to do so. I’ll get to that later. What I want to talk about today is the responsibility that playing out a project like this in public brings with it and how, in my opinion, AlphaGov have let down both the UX and Inclusive Design/Accessibility professional communities. What you do, not what you say Let me start by saying that I have a lot of admiration for the the ambition of this project. There is a lot that is good about it. There are also a lot of smart and talented people on the team. The first thing that strikes me as strange is that on a project that claims to have an obsession with meeting user needs, the team contains a visual designer and a content strategist, a general strategist and multiple search analysists but NOT a user experience lead. That’s right. We have an obsession with meeting user needs but not so much that we’ll actually hire someone who has extensive experience in actually making that happen. Now, the project was fortunate in that it had Richard Pope, who I first met when he was a very UX-savvy developer at Moo and who  played the Product Lead role on AlphaGov. As far as UX resources go, you could do a lot worse. The team also recruited Paul Annett later into the project. Paul also has some UX experience but, as I understand it, his role was primarily as visual designer, making the interface a nicer place to be. Without commenting on the interface itself, the lack of a rigorous approach to user experience is very evident in the way that the team talk about the work that they have done and their ‘design rules‘. In a recent blog post about their agile methodology Project Manager Jamie Arnold describes exactly what this ‘obsession with user need’ entailed: We spent the first two weeks in February recruiting a team from inside and outside of government, talking through the scope, agreeing some design rules and agreeing a vision for the Alphagov product based around the recommendations of Martha’s report. We ended those two weeks with a list of prioritised user needs (based around search analytics from Directgov, Hitwise and departments), We roughly grouped into functional areas and stuck to the wall. Each card (or user story) represented a user need, prioritised roughly from left to right and top to bottom. Crucially also there was a fair amount of @tomskitomski and @memespring‘s product experience. All this was more than good enough to get on with twelve weekly development sprints. More than good enough, eh? For many projects this would have been more than they ever had to work with. But this is not just any project. This is a groundbreaking, whole of government initiative that claims to take a User Centred approach and be obsessed with knowing and supporting the end user need. I think a project like that needs to demonstrate User Centred-ness a little more rigorously. For example. Who is the audience? At no point that I saw did the AlphaGov team ever apparently think deeply about what kind of an end user they were going to prioritise. They talk about ‘thinking about who our users were’ and having a ‘user-base of all the entire adult population of a country’. As User Experience practitioners we know that although you might want the whole country to use whatever you’re designing, you need to put a ring around the kind of users you MOST want to support. As designers we always privilege some behavioural attributes over others, even if we don’t articulate it. By not thoughtfully articulating this, you risk either an incoherent approach to the experience design or resort to self-referential design (designing for your own behaviour – something that is incredibly difficult to overcome). You can’t take a User Centred approach to design when your user is ‘Everyone’. You need to define who your users are. You must clearly identify the behavioural characteristics that you most want to support and focus on designing to best support these. There are many valid design approaches that do not require such a clearly articulated definition of the end user, but these are NOT user centred approaches. Thinking generally about ‘users’ while we design is not doing user centred design. I think it’s pretty irresponsible to suggest that it is. AlphaGov sends a message that you can say you’re doing User Centred Design but you don’t have to show any evidence of a UCD process – audience definition, research, user involvement, design principles that actually track to specific behaviour attributes. For example, it would have been great to see some personas developed and shared for this project – even hypothetical ones that drew on the data/insight available to the team. As well as helping the team avoid the problem of the ‘elastic user’ (particularly problematic when you do think your target audience is everyone), it would also help us be better able to evaluate what is good and bad about the prototype. It would also have demonstrated that the team was actually practicing User Centred Design. (Elastic user, for those not familiar with the term, was coined by Alan Cooper to describe the way that while making product decisions different stakeholders may define the ‘user’ according to their convenience, often resulting in self-referential rather than user-centred design. More here). This leads us to one of the complexities of the AlphaGov audience which is that, in reality, rather then being obsessively user-centred, the project had two competing audiences. The largely undefined end user and, often more importantly, the stakeholders who would ultimately decide the fate of the project – public servants. These two audiences have VERY different motivations and goals for this project, and the impact of the latter on design decision making was never clearer than when the accessibility topic came up. On Accessibility and a conflict of interest Again, from what I know, there was no formal expert accessibility (or inclusive design as I prefer to call it) consultancy on the project team. This is not to say that the team didn’t have quite a bit of knowledge about the mechanics of accessibility (the impact of technical decisions on whether something could be certified ‘accessible’). The team sets out a really thoughtful understanding of what it takes to make a service properly accessible: Accessibility should start with research and consideration, not with box-ticking or sprinkling a few standard accessibility features – especially in a government context where a user journey regularly extends into the real world (Booking a driving test? You’ll probably want to know the facilities at the test-centre). Ultimately, the AlphaGov prototype doesn’t make any significant attempt at achieving accessibility (particularly making a site that works fine even with JavaScript is switched off) apparently due to the short timeframes and ability to ‘retrofit’ accessibility later (hrm). Actually, what I picked up from discussions about this on Twitter and elsewhere was that actually, it was the other target audience – the stakeholders – who most influenced this decision. If they put the focus on accessibility, they’d have to take away some of the ‘shiny’ – AlphaGov would end up feeling like Just Another Government Website. Rightly or wrongly, the shiny would help excite the public servants to approve and fund a beta version of the prototype. Perhaps it was a noble sacrifice… who knows. Point is, it’s far from transparent. The message that the world takes away from this exchange is that accessibility, even when your audience ‘entire adult population of a country’ is optional. And that accessibility can be ‘done later’ not, as they had first set out, built into design considerations from the outset. These are really bad messages to be sending and, given how publicly visible and lauded this project is, sets the work of many amazing inclusive design specialists back considerably. It’s hard enough to sell in good accessibility work already. AlphaGov just made it harder. Activity Based Design and Search Analytics OK. So I will talk briefly about the prototype… but mostly to discuss how the data you have access to can significantly shape your design. The team have published very little information on the data that has guided their design decision making for this project but we do know that search activity has influenced it heavily. A team of sixteen people included no UX lead (sorry, did I mention that already?) but two people doing search analysis. In the design rationale blog post, Richard Pope implies that search logs strongly influenced the design and information architecture strategy for the prototype. we spent the first couple of weeks scouring search logs and analytics for the various central government websites; thinking about who our users were and generally discussing the kind of thing we were setting out to make Based on what we learned from looking at search-logs, we knew that there was a relatively small subset of tasks that require the majority of people need to interact with government online. So we should do less and focus on tasks. Since for the vast majority of people their web journeys (finding out the date of the next bank-holiday, or reporting a lost passport) start with a search engine rather than a direct visit we should think of Google as the homepage and we should also feed Google, Bing and other search engines nice friendly urls. If someone is just landing at a page on your site then it’s helpful to start thinking of every visit being a new user, assuming they have no prior knowledge of the structure or content website they have landed at. It is really difficult to evaluate this prototype from a user experience perspective, given the competing target audiences. The best you can do is try to recall the last few times you interacted with a government website and try to reenact that here. Every time I do that I come away with a lingering feeling of disengagement. There’s something that search logs probably don’t really show which is that this is MY government. For better or worse, I have a long term and multifaceted relationship with this government and yet, every time I encounter this site it (by design) makes me feel as though this is my first visit. I find that really unsatisfying and kind of perturbing. Now, this is not a professional design critique, this is a qualitative research data point of one. But it’s not something that you’ll ever pick up from search stats and analytics. I could bore you further with how I find the promise of localisation with this infinite noob status even more perplexing, but you’d have to spend time with me to understand it. And then spend some time with a bunch of other people to see if this is a common theme or just me being an edgecase. And people will never post this kind of feedback on GetSatisfaction. (Most people can’t really articulate this kind of weird feeling and wouldn’t think that it was important enough to comment on compared to, say, a bug. You need a good facilitator to extract this kind of data). To do really good user experience design you need a mix of data points. If you privilege one set of data, you’ll see that in your design. I think we’ve got some of that going on with AlphaGov. Quantitative data is fantastic. I’d love to see more of what the team had to work with and how they applied it in their design process. But it’s just one kind of input. Qualitative research helps you better understand your end users and thereby to design better for them. People who do User Centred Design do Qualitative Research. User Experience is a Time Soak/Non-Agile Which leads me to the final problematic sub-text that I felt emanating from the AlphaGov team which was essentially that ‘we’re as user centred/accessible as we can be given that we only have 10 weeks to build this thing’. This perpetuates the myth that User Experience can be a time soak, that it slows you down, that it doesn’t really have a place in an Agile methodology. This is where having an experience UX practitioner on the team from early on could have been helpful. It is certainly true that historically, Agile and UX have had a fairly vexed relationship but these days many practitioners are experienced and adept at including both user research and ux design into the most demanding agile iterations. We have a toolkit of lightweight qualitative research approaches that work beautifully in this kind of fast paced and responsive environment. UX does not have to be a laggard either at the outset or in the throes of an agile project. The ten week project timeframe is absolutely no reason to not include real practice of user experience in the process. You may need to find someone who has experience working this way (not all UXers find this kind of project much fun), and you may need to be creative in the way you structure the work, but you should definitely be doing it. Particularly if you’re setting an example of how projects should be done, as the AlphaGov team certainly was. In conclusion I want to repeat again, this is a very worthy project and many of their design principles are, I think, sound. For many commercial projects, the methodology that they’ve applied and shared is absolutely appropriate. But the bar is set higher here. By doing this project in public, by making such a big deal of putting the end user needs and their importance to the project, the AlphaGov team have set themselves up as rolemodels. They’re sending messages about the the way things should be done. They’ve made quite a rod for their back. If I was just a member of the community, I’d probably be nothing short of delighted with what they’ve achieved. Unfortunately, as a User Experience practitioner, I feel kind of glum. This project has talked the talk of caring about the end user, of placing their needs at the centre of the project and above the needs and desires of government, but at every step, they’ve done little to set a good example for how others should actually do this. I hope AlphaGov does move forward into BetaGov. But I hope, if they do, they take a moment to think about what the public performance of AlphaGov and then BetaGov means for their professional community. Either stop calling the project User Centred, or hire someone to really focus on user experience and do more to share how they’ve integrated real user insight into their design strategy and implementation. There’s a big opportunity to set a good example to a big audience here. Let’s take advantage of that opportunity and show the UK Government, digital industry, hell, the whole world what projects really look like when they’re user centred, – that they don’t have to be cumbersome, expensive and slow. Imagine that, a properly user centred government website that was agile, and shiny and amazing. Now, that’s something to get excited about.

---

During a Drupal.org redesign sprint at one of the recent cons, there was a discussion at about the branding of other Drupal properties, e.g. Drupal Association, Groups, API, etc. Specifically, we discussed if the theme for the Association site would use the standard wordmark, or if we would create property specific wordmarks so users have a better idea of where they are. I'm pretty sure this discussion was abandoned in the interest of time and just proceed with using the same header/logo as the Drupal.org theme. Another reason for doing this would be to give a facelift to the outdated Drupal Association member badges. Overall, I've been pretty disappointed at the slow adoption of our new wordmark. In an order to combat this, I've create a page which allows users to download the logo while providing them with the proper usage guidelines -- drupal.org/drupal-media-kit. I've got a few ideas that I can follow up with anybody that will listen, but I just wanted to get the conversation started. Drupal Association improvements to Drupal.org

---

As you may know, I’m working with the Drupal community on a (voluntary) Social Architecture Project called the Prairie Initiative. We’re looking to tune up Drupal’s collaboration tools so that it’s an easier, more efficient and more collaborative place for all the different disciplines that Drupal needs to be great. If you’ve got any experience attempting to, considering or actually contributing to Drupal, I’d really appreciate if you’d come take our sentiment survey. We’re taking a benchmark now and will check back every quarter to see if and how any changes we make impact this and some other metrics. Much appreciated.

---

Understanding user behavior using Google Analytics. To do the same we will need to take small steps in the way drupal.org code is rendered as detailed below: Add on page js tracking, this is adding a small piece of js to the file download links throughout the site. Example the URL for Drupal 7 tar download should have the js embedded into code as in attached file. Reference:On page js tracking: http://www.google.com/support/googleanalytics/bin/answer.py?answer=55529 Identify which part of the site the user visits by adopting proper url strategy. Most of our pages read node/, to help identify he same we should come up with a site URL architecture. eg. All documentation pages should read: http://drupal.org/documentation/page-title, forum pages:http://drupal.org/forums/forum-name/page-title and issue queues: http://drupal.org/project/issues/project-name/page-title This will help us identify which are the section users spend more time on, understand user behavior based on user segments, Introduce a thank you page on completion of user registration, or submission of member registration. AttachmentSize On Page Tracking.html219 bytes Drupal.org Improvements

---

The draft policy, procedures and requirements for bringing *.drupal.org initiatives onto the live sites are published here: Process for getting changes deployed on drupal.org Drupal.org development guidelines Hopefully as ideas are generated and refined through the Prairie Initiative and people start implementing solutions, implementors can be proactive rather than reactive to the process and requirements necessary for improving Drupal.org. Prairie Initiative

---

We have almost 247 individuals to be reviewed. Thus I hang myself out there put My neck on the line and am demanding change. If this ruins My reputation, then so be it. Ok, so I started this conversation with an attention grabbing headline, but I truely believe it. I have had so many people come in and ask about the status of their code going from sandbox to release. The problem, people waiting a week or more for their project to even get a response from those few brave soles who have volunteered for the review process. Now I have followed up on this and even talked to the head of this review process, and it simply is too cumbersome to continue. We are taking our next generation of contributors telling them to hurry up and wait. This is completely unacceptable and as one person stated "Its like running out of gas while idling." We have to get the module's to open up to all and we can not wait any longer. EVERY day we wait is another day that we may loose the next Merlin, CHX, Michelle, Webchick or the numbers of other people who do tremendous thankless hours of work. These people will move onto other CMS's. Problem The problem is that it does limit the ability to have application developers to get their code out. The system is logically sound, but is impractical due to resources. If we had enough code reviewers where the average turn around on a response from the issue querry was a day or less the system would be great. If the system took 1 week for a module to get published I would not be here to have this discussion with you. I was upset when I thought the process took 2 weeks, but when I heard that was incredibly optimistic and that it was around 2 MONTHS, I could not sit back and let this happen to Drupal. This will KILL the entire project! History When I started with Drupal, I made a horrible little module that was poorly formatted and barely passable for a spot on the website. CHX looked at a few files and put the project on the site. Within minutes, I started to get feedback on how to make my horrible module meet standards. I got patches and other things, and I quickly improved my module. The only committee I had to face was my peers. Fellow Drupalers. That small 5.x module is still beign used by 10 people (even though control of it has been passed over to another maintainer), and there are people requesting for it to be upgraded. 10 people who needed what I had done is a rather good achievement for that little scrap peace of code. Not to mention that process got me too write better code and to follow Drupal standards. The system did everything it was suppose to and no one did anything intentionally to make it work. Somewhere along the line (around a year ago) the idea that standards are optional became standards are a must. This is a HUGE mistake. Hacking (not the illegal type) is a VERY valuable asset to a community, and GREAT hackers are can not only be visionary, but can create incredibly powerful applications, and they do so by breaking what was once considered traditional boundaries. We do not want a system that eliminates hackers via a review process. From the discussion with Zzolo, the head of this process, and others the idea for the current system was not to hinder the module development process but to offer mentoring and to increase the uses of Drupals coding standards. How the Review process works NOW! People, with the best intentions, created a process where modules are put into the sandbox. The idea was to hook up new contributors with mentors to improve module quality and release higher quality modules. In practice this is a process intensive task that requires a tremendous amount of work from volunteers we simply do not have enough of. What has been Suggested! Some have suggested creating bots to go through and review processes based on a set of rules. Some have even started this process. But those of us who have worked with making changes to drupal.org know, that these if this was written tomorrow, it would take months, if not years to make it up onto the site. Others suggest that we need more reviewers. Well how long are we going to wait for this staff of people who are willing to go over other peoples code and comment on how to make it better. From what I see this process has been in place for well over a year, and we still dont have the staff. I have heard concerns about "Drupal" becoming a "Dumping Ground" for all sorts of stuff (not the actual word used). Well why is it that Joomla and Wordpress do not have any such review process. I am sure there are a hundred other reasons why we should hold off, but I can give you 1 reason why we cant wait. We are turning people who are offering their time to Drupal and telling them to hurry up and wait. We beg for their help and then ask them to hold until we approve of their work. That is not only impractical but insulting. If I had to go through this with My First Horribly written module, I would not be here today. Solution The solution is simple, if a module has a GNU/GPL licensee, a Read Me and will register with the update system it is in. Allow anyone who has a level of trust and a moment to look for these few things to turn a sandbox project into a project featured on our page. Do this IMMEDIATELY! Next, we may want to change the review process into a mentoring process. Allow module maintainers to work towards a coveted achievement of Approved Drupal Module developer or any other title you wish to give them. Hell, make a small smiley face to put on their profile. If you doubt people wont do what it takes to get this, ask the millions of people who have spent 100's of hours killing a gazillion bad guys in any of the popular games, just so they could have the distinct title of "Super Bad Guy Killa!" We should work towards a peer review system and put a rush on the metric proposal. Wordpress and Joomla both have rating and peer review systems in place, and I would be surprised if the majority of other CMS systems do not have a similar feature. Lets say that 1/100 people contribute modules, then regardless of how big our population grows, we will continue to have a proportional number of people to review modules. Lets face it, everyone has an opinion, and getting that opinion is not hard at all. Lets utilize these opinions and these people to make their own voices heard on what is and is not good for them. If someone makes a module that says "Hello", I may not like it. I may find it stupid. But who am I to tell you that its an invalid idea. Who am I to tell you that no one will use it. Let the public decide who uses it and who doesn't. Conclusion Stop reviewing all modules outside of the scope for the most fundamental basics. Then lets work on solutions that are not only positive, but can actually be implemented. I will not accept delay, this is simply too important for that. I will not watch another contributor go to word press to develop their modules. After that is done, lets talk about other solutions to improve the quality of the modules we have and to improve the ability for the consumers of those modules to decide for themselves what they want. -Some will see this as being aggressive. But make no mistake, I do not wish anyone harm. No one is to be blamed, hung or insulted. This was a Great idea that works on paper but fails in practice. But this needs Buzz, this needs attention, and this needs to be fixed. Hang Me if you want, but please save Drupal. References: http://drupal.org/project/projectapplications http://drupal.org/project/issues/projectapplications?categories=All http://drupal.org/node/1011698 http://drupal.org/node/713102 http://drupal.org/node/645470 Prairie Initiative

---

The thing I commonly find with forum/committee based systems is that they become very set in their ways. The systems become very difficult to change, and the hostility within these systems are most often sharp as a knife. Contrasty, open community based systems (like those found in "social networks"), are naturally less hostile, more flexible, faster to change with the tide, and able to meet a the needs of a much larger target audience. This document is an attempt to reduce duplication, increase information accessibility and provide additional flexibility. In addition it will attempt to explain a system which will increase collaboration and decrease hostilities towards change. Thus promoting a healthier environment that accepts rapid change and reduces I have seen, and even proven that the way in which a system is built directly effects the culture that is within that system. Thus carefully made systems tailored to their audience actually promote growth, improve communication, promote change, reduce hostility and reduce information duplication. Time after time Drupalers (is that a word?) find the most brilliant ideas in the eyes of the new comer. Their fresh perspective is amazing, and sometimes brilliant, yet time and time again we crush these individuals hopes through miles of red tape and political mess. Often times this is a issue of conflicting ego's, other times its a resistance to change, while many times its simple pride. None of these reasons create a healthy social environment that benefits the community. I think the current Drupal system regarding changes to documentation and core unintentionally puts up these barriers. Its time to tear these barriers down. Content Example of the problem with the current system is found in the way in which we manage documents. Currently if I disagree with the current document model I have about 2 years of work ahead of me to change it. That is IF I can get all the interested parties involved to agree to the new model. But as we have seen in the redesign of this site, and the many attempts to improve documentation, this process is extremely hard, if not impossible until the issue becomes critical and only then is it possible to change if the major players get involved and really start compromising. The example provided in http://www.archive.org/details/GrouptheNewOrganicGroups-BuildingSocialNe... is amazingly accurate. OG has progressed to such a wonderfully powerful and flexible tool for so many applications that we should seriously consider it and its impacts on Drupal.org! Thus when I talk about groups I talk about them in the extremely flexible OG 3.x model seance. In essence, Groups are one way in which content is distributed and consumed. Which means that Documents, and Discussions could all belong to one or more groups. If I create a group I should be able to add content to that group regardless of its type. Thus I can include a "fixed" ticket in My Group along with a Document someone wrote. As the maintainer of the group I can thus create unique relationships, formulas and recipes between content without adding duplication. If I create a group, I should be able to add content to that group regardless of its type. Thus I can include a "fixed" ticket in My Group along with a Document someone wrote. As the maintainer of the group I can thus create relationships between content without adding duplication. If I disagree with how THIS group is run (for example), and can not get it to change, currently I can not "Fork" it by creating a new group. The "Forking" idea is not a favorable outcome but sometimes their are more then one valid approaches. If I decided to "Fork" this group, its not that I do not see this group as invalid, its that I see a different approach to be more valid to Me and/or My target audience. Its not a black or white world, its grey. I am not a threat to this group, I am simply offering an alternative for a different audience. The Drupal community does a great job at dealing with Forks of modules. We discourage it but do not prevent it. I purpose this same attitude towards groups. Also if someone abandons an active group, the same process of obtaining control that we use for modules would work in an open system of groups. However I don't see "forking" in a group occurring any more then forking in modules occur. In my years in Drupal, I have seen things fork, only to later come back together a year or two later (Example, nodeprofile, bionode, etc) or stay separate and provide two distinct yet equally valid options (the commerce system, Notifications/Subscriptions, etc). Prairie Initiative

---

Drupal is quickly becoming a product where less and less custom coding will be required for new sites. With modules such as Views, Panels and Webform combined with advanced, and user friendly, themes, sites will be possible to build without knowing anything about coding in PHP etc. Drupal Gardens and Buzzr are great examples of this. Distributions is also making site building much easier to get started without coding. Hosting companies are making Drupal very easy to install with just a few clicks. I'm not talking about the traditional one-click installs of old versions. Now these companies understand that providing good Drupal support gives them en edge on the market. I think that we do realise that this is going to attract the same kind of users that today download and install WordPress. A lot of these new users will have very limited coding skills. In fact, most them couldn't care less about it. The only thing they are interested in is to get a software they quickly can build a site with. Unfortunately most of these new users will run away from Drupal! This is why: WordPress.org Scares me We compare Drupal with Wordpress, but have anyone really compared the community websites properly? Spending only a few minutes on wordpress.org was a very scary wakeup call for me about how far behind we are. What immediately struck me was that everything there is about using WordPress, not developing it. When I search for modules, themes etc the information presented is about stable releases, how to install them and so on. The closest you get to coding is a link, in the sidebar, to the developer log. That's it, nothing that can create confusion for new users! The site also checks what languages I have configured my browser for and kindly tells me that: WordPress is also available in Svenska and Español. On the forum page it tells me that they also have dedicated Spanish forums. I was extremely impressed about how well structured the site is and that they have realised that new users come to learn how to use it, not develop for it. Drupal 7 is a fantastic upgrade and so much more intuitive and user friendly. But if we cant back it up with an equally good user experience on d.o, then we will gain only a small fraction of the potential number of new users possible. Try d.o as a new user with no knowledge As an exercise I suggest everyone try to get a WYSIWYG editor working on a fresh Drupal 7, including enabling it for the article content type and make the first post. Use the built in "Install new module or theme" feature in Drupal 7. Here is the catch - Pretend as if you know nothing about coding and you don't want to learn. You also have Drupal amnesia. Push all your Drupal knowledge aside as if you never learnt it. Then open drupal.org and look at the information and imagine what a new user would do in the same situation. Don't cheat, force yourself to really think as a novice! I did this yesterday and it wasn't funny at all when I realised how bad state it actually is in. The Drupal slogan is: Come for the software, stay for the community Even our slogan says that it is the software new users comes for and that the community is something they will learn to love and stay for. But how many are giving up long before they find that love? Unless you have good experience, preferable as a web developer, d.o is going to fail in providing you with what you need. It will only "confirm" that Drupal is difficult to get started with. I think it is time to realise that we have a lot to improve... From one extreme to another To summarise this I can say that comparing d.o and w.o is like comparing one extreme with another: Wordpress.org - 100% focus on using WordPress. Every hint about what it is built in is carefully removed to not confuse or scare away new users. Drupal.org - >90% focus on coding. As a new user, even with some skills, it is extremely difficult to find information. Everything seems mashed together and it is more or less assumed that you already know what your looking for. The problem is that both compete on the same market, and Drupal is losing badly! In my option, w.o has gone too far. They have made it very difficult to find any kind if developer information and code examples. They have even hidden login/account creation from most pages. I completely understand their reasons behind this and why it is successful. I don't want the same on d.o, but we need to understand that we need to better separate the available information based on user needs. New users want to learn how to build their sites. Later on many of them will discover all other wonderful aspects of the community. A simple thing such as the everything listed on http://drupal.org/download must be officially released versions would be a great start. Our strength is the fantastic developer community and the infrastructure it has created. It is a great foundation to build on. Ask yourself - As a new user wanting to build a site, what you would have selected after spending 30-60 minutes each on w.o and d.o? I am sure that this text would not have been written if all wanted was a site building tool a few years ago! Can we do something about this? Of course we can! Drupal Association improvements to Drupal.org

---

drupalredesign: got PHP/jQuery chops? Fancy doing some usability testing? #D7UX needs your help. http://bit.ly/6xH8zK/

---

drupalredesign: excited to see the launch of #d7cx - Drupal 7 Contrib experience: getting the top 40 contrib modules D7 ready! http://cyrve.com/d7cx

---

drupalredesign: check out @jeffnoyes' proposals for #d7ux shortcuts: http://blip.tv/file/2304921 and appearance/themes section: http://blip.tv/file/2290150

---

drupalredesign: D7UX Information Architecture - A detailed view: http://bit.ly/D136E

---

drupalredesign: D7UX Information Architecture Strategies: http://bit.ly/k6Xs1

---

drupalredesign: Understanding the D7UX Information Architecture Approach (with thanks to @royscholten) http://bit.ly/1Yce76

---

drupalredesign: 5 microprojects launched today and more to come soon! http://bit.ly/PqobG #d7ux

---

drupalredesign: Take our Common Site & Content Type Survey for #d7ux - it's quick and open to anyone who builds/designs/manages websites http://bit.ly/4cndt

---

drupalredesign: The best possible thing you could do this Sunday - participate in Structure Summit Sunday http://bit.ly/sHKBD #d7ux

---

drupalredesign: Roles & the Admin Header, proposing a new default role - 'member' #d7ux http://bit.ly/8LcZq

---

drupalredesign: Drupal developers - got a module that could do with some User Interface expertise? Nominate it for a #D7UX Microproject http://bit.ly/pz1OV

---

drupalredesign: User Experience People - Want to dip your toe in Open Source Design? Try a D7UX Microproject http://www.d7ux.org/microprojects/ #d7ux

---

drupalredesign: question: what's the average no. of content types in your Drupal built site? http://bit.ly/1YmyT #d7ux

---

drupalredesign: who is D7UX designed for? http://www.d7ux.org/who-is-d7ux-for/

---

drupalredesign: Drupalers - how do you use Taxonomy? How do you usually create content categories in your Drupal sites? http://tinyurl.com/pugxpg #d7ux

---

drupalredesign: @markboulton & @pixeldiva talk accessibility & #d7ux http://www.d7ux.org/accessibility/

---

drupalredesign: D7UX Update - people have been asking what we've been up to, so here's a little update: http://www.d7ux.org/update_13may/

---

drupalredesign: D7UX & Accessibility - what are your big questions, concerns, suggestions for what we need to look at. Tell us here: d7ux.org/accessibility

---

drupalredesign: help pls? what do you think are the top three tasks for these user roles? http://bit.ly/w6X5p #d7ux

---

drupalredesign: A review of D7UX brainstorming in London last week (thanks @jeffnoyes) http://tinyurl.com/c8febv #d7ux

---

Chris Charlton posted a reply: Just saw, I'm getting caught up.

---

Rob Mills posted a new topic: the comments on this flickr group tie in nicely with a task at: www.disambiguity.com/ perhaps some of you could post some wireframes over there.

---

Rob Mills posted a new topic: Hi All, I posted quite a few screenshots of other blogging/CMS/open source sites etc. Would be really interested in people's comments on what they like and dislike about these sites. What can we learn from them for the drupal redesign and what should we avoid and so on ... Thanks Rob

---

A Keynote presentation at Drupalcon Szeged, Hungary 2008. Presented by Mark Boulton and Leisa Reichelt

---