SEO Expert Blog

FosterClub Drupal developer Employment type:  Contract Telecommute:  Allowed Looking for someone who can make our current Drupal site interface with LimeSurvey for a large survey project for a non-profit located in Oregon. Must be able to ensure security of data and must be located in the USA. Please send inquiries to celeste@fosterclub.org, along with a description of similar projects (viewable samples appreciated). http://www.fosterclub.org Drupal.org redesign plan for the Drupal Association

---

One of the big goals of the drupal.org redesign is to make it easier for end users to find the right modules for the site they're trying to build. With over 5,000 contributed modules, many of them providing similar functionality, it can be extremely difficult to choose. One method is to try to assess the "health" of the module, by how actively it's maintained, used, supported, etc. One approach to gauging health is posted at Project ratings and reviews for drupal.org redesign. While that proposal deals with subjective factors, this post addresses objective facts about a module that can be computed and displayed for all projects hosted on drupal.org. While no single metric can tell you what module to use, and some knowledge will be required to make the best use of this data, it's important to make these statistics more readily available on drupal.org to empower users to make better decisions. The redesign prototype for project pages includes the introduction of a sparkline showing the "Activity" for each project. The details of this activity chart weren't specified at a technical level during the design phase, but the spirit of the design is that they wanted more ways to visualize the health of a project. As we're implementing the redesign, we've been empowered to provide as many charts containing specific data we think will best help end users make sense of what's going on with a project. Read on for our specific proposal, including what metrics to compute, and some ideas on how those are going to be visualized on the new drupal.org Specific metrics There are literally dozens and dozens of metrics that could be captured and displayed. We've already got support for the usage of any given project and we're working on support for download statistics. Beyond those, we believe the following are important to assess the overall health of a project at a glance: Issue activity: Each project category (bug, feature request, etc.) -- number open vs. number fixed/closed Number of issue reporters (unique users filing new issues in a defined time period) Number of issue participants (unique users filing issues or comments in defined time period) Total number of issue comments posted over a week (ideally with a separate total for the number of comments by any of the project maintainers, both of which can be graphed on the same sparkling). Release activity: Number of releases in each time period We're proposing to normalize all metrics to a weekly granularity. This would both simplify the storage (so we're not trying to store daily metrics) and the UI (since it'd be best if all the charts used the same granularity to make it easy to compare them). Additionally, the following metrics could be useful, but we might not have time to implement them for the initial launch of the redesign: Commit activity (This would be great, but it's not worth our time to add this for CVS with the Git migration imminent). Number of lines added/removed Number of commits Total number of tests and percentage of tests that pass Total lines of code vs. lines of comment Average length of time that issues are open Number of unique users submitting patches reviewing patches We're trying to strike a balance between what's relatively easy and sane to compute, implement and display visually, and things that will help users find the best project for their particular needs. Given that, if you have suggestions for other metrics we should be considering, please comment below! Enter the project_metrics module We looked at a lot of Drupal charting modules (see below), but basically none of them handle the storage for you. So, no matter how we end up displaying this data, we need somewhere to compute and store it. Enter the project_metrics module. This would be a new sub-module included directly in the Project project. While the project_usage module is really only relevant to sites that are using Project to manage releases of Drupal code to track update_status usage, the project_metrics module could be useful for just about anyone running the Project suite. It would be responsible for computing the metrics and storing them. To compute, the idea is we'd write a series of drush commands that would be run periodically to do all the heavy lifting to compute the right statistics for a given week. These commands would insert records into the project_metrics module's DB tables. Then, project_metrics would provide various ways to access and display the data (see below). The basic architecture of the module is that it would invoke a hook to allow other modules to advertise what metrics they want to provide. The project_metrics module would then be responsible for invoking the appropriate functions in the other modules at the right frequency and storing the results. So, project_metrics itself wouldn't know how to query the issue database tables looking for statistics. That'd still be the responsibility of the project_issue module. However, project_issue wouldn't have to worry about invoking itself via cron, wouldn't have to manage its own tables to store the historical data, etc. Front-end display So how would all this data be visible on drupal.org? The key metrics would be exposed via sparklines on the project page itself. Depending on how many metrics we end up with, we might need to add a tab off project pages (or use JS to show/hide the full list of metrics) so that it's possible to drill down and find as many statistics as we provide, without overwhelming the user with all of that data directly on the default project pages. My vision is that there's an easy way to see 5 - 10 sparklines, each with datapoints at 1 week granularity, all vertically stacked so the weeks line up. That way, you can see how the different metrics correlate. So long as the scale of the horizontal axis is the same on all graphs (so they line up and are easy to compare), we can use a different scale for the vertical axis for each sparkline so that they all make the most visual sense (e.g. the number of releases in a week is probably going to be 0-4 most of the time, whereas the number of issue comments or lines of code added/removed could be in the hundreds or thousands). With the charts stacked so the weeks line up, you could easily see for example that one week the "number of lines of code added/removed" sparkline goes nuts, and the "number of open bugs" chart started climbing soon thereafter. ;) There are some metrics and statistics specifically about the issue queues that are already on drupal.org, they're just mostly hidden. For example, you can view statistics about the Drupal core issue queue. This page will probably get some much-needed attention (it hasn't been touched in years). Although none of the UI parts of this proposal are set in stone, it's likely that we'll update these per-project issue statistics pages to include more of the issue-related metrics discussed above. The idea is that we'd put the current week's raw data in the tables near the top of the page, and then provide sparklines below to see how those values have changed over the weeks of the last year. Additionally, we're going to expose some of these metrics to Solr to make it possible to filter and sort projects by various metrics. We've already done this with the project usage data (for example, this is the default sort order when you browse module projects on drupal.org). So, in addition to being able to sort by "Most installed" (and hopefully soon, "Most downloaded"), you might also be able to sort by "Most active issue queue", "Smallest % of open bugs", "Most commit activity", etc. However, when it comes to visualizing the data that the project_metrics module would be providing, we've investigated a few possible ways to generate the necessary charts: Sparkline-aware views display plugin We could expose all of the project_metrics data to views, create views for whatever we care about, and write a Views display plugin that knows how to render our results as a sparkline. This could potentially be done as part of the Views charts project, or as its own new "Views sparkline" contribution. Either way, we'd hope to make use of the Sparkline module. The Views display plugin would simply be glue to take the data from the results of the query that Views ran and format that data in a way that the Sparkline module expects to be able to generate the sparkline itself. Charts API We could potentially use the Charts API to handle our charting needs. We'd still probably drive the queries via Views and have a display plugin to render the results via the Charts API. So, this is more an alternative to the Sparkline module itself -- either way we'd probably be exporting the project_metrics data to Views and writing a display plugin. Quant We looked at the Quant module, but it doesn't really seem like it gets us very far. It can do really complicated queries to try to figure out the historical data for you, but that's going to probably kill the d.o database server. It doesn't do any storage for you. And, we'd have to write some code to expose our data to Quant. At that point, we might as well just expose it to Views since that seems a lot more flexible and powerful. Implementation roadmap From now until around August 20th, we're just going to gather feedback on this proposal. To prevent the discussion from getting fragmented, please add comments directly on this post. Starting around August 23rd, we're going to begin implementing the project_metrics module, and any changes to the rest of the Project suite, to make it possible to compute all these statistics. We expect all the backend work to take approximately two weeks. Starting around September 7th, we're going to evaluate the front-end options and pick one to roll out on drupal.org. We're aiming to get these metrics visible on project pages and in the ApacheSolr index on the live drupal.org independent of the launch of the redesign theme (which is called "bluecheese"), unless it involves significant work in the existing drupal.org theme ("bluebeach"). Background reading Interested readers can check out the following threads for more on this juicy topic: Project Quality Metrics on Drupal.org (meta document) Automate gathering of quality metrics Project module's hidden project metrics Drupal.org redesign implementers

---

One of the major new features proposed in the redesign site prototype for making it easier to find the right modules for end users is the introduction of Project ratings and reviews. This post is a proposal for how we're planning to implement these features as part of the redesign. If there's sufficient traction for this proposal, we could actually roll this out independently of the redesign theme launch itself. So, if we can converge on a plan, we could actually see this live in the next few weeks... Asking the right questions for ratings Unfortunately, the redesign just proposes a simple "community rating" concept, using a single 5 star voting mechanism. However, for the information to be meaningful, you have to ask the right question that you want people to vote on. The point is not a popularity contest, it's to help give users a sense of what to expect if they start using a given module or theme on their site. We propose asking 4 key questions to allow users to rate subjective factors about any given project beyond the objective factors that can be measured via the automated metrics we'll also be adding as part of the redesign (more on the automated metrics in a future post, stay tuned). I checked out drupalmodules.com, and they also use a multi-dimensional rating system. Although a few of the questions are good, I think the others aren't that helpful. Here are the things we're planning to ask people to vote on if they're going to rate a given project: Works as intended Does the project actually do what it claims it does? Does it work well? Well maintained How responsible is the maintainer? Are there new releases at a good frequency? Are they careful about testing before releasing? Ease of use How easy is it to use this project? Is the UI self-explanatory? Documentation Is there good documentation? Is it clear? Is it sufficient? Mostly, we'd just show these values independently, and let users decide for themselves which ratings are the most important when trying to decide if they want to use a given project. However, there are some places in the redesign that rely on a single "Top rated" notion, so we're going to have to provide an average rating across all questions. Reviews In addition to numeric ratings on the above questions, we want to give users a chance to provide a free-form review of each project. Although there's a chance some users will use the reviews as another channel for support and bug reporting, we believe that with sufficient warnings on the form for creating a review, and a general culture on drupal.org of collective moderation, this won't become a drastic problem. The redesign also provides for a "was this review helpful?" feature, so we can use something like vote up/down and bury the useless reviews and promote the more useful ones. Implementation details I think the simplest and best approach for getting all this working would be to introduce a new "project review" node type. The ratings themselves could just be numeric CCK fields on these nodes. I think it makes sense that you have to create a review if you want to rate something, since it's a good thing to be able to provide a rational for the way you voted. None of the fields would have to be required, so you could just write a review and not cast a rating on any of the questions, or just rate a few of the questions but not all. So, this project_review node type would have the following fields: title none/hidden body text area labeled "Review" project node reference to point to the project the review is about -- this would be pre-populated based on a final argument to node/add/project-review, e.g. http://drupal.org/node/add/project-review/views or something works as intended CCK numeric field with 0-5, optional, defaults to null (not specified) well maintained CCK numeric field with 0-5, optional, defaults to null (not specified) ease of use CCK numeric field with 0-5, optional, defaults to null (not specified) documentation CCK numeric field with 0-5, optional, defaults to null (not specified) core version use the same taxonomy that project_release nodes use for the core version (to target the review to at least a version of core) project version (maybe) optional node reference to point to a specific release node of the project -- not sure if we need this level of detail. yes, ratings + reviews could be pretty different across major versions (e.g. the 6.x-1.* branch sucks, but 6.x-2.* is much better). But, I don't think we want to require pointing to a specific version all the time. This aspect still needs a bit more thought. The idea would be to add a project_review module as part of Project itself. It would just expose this CCK node type and the required fields programatically, so that a site would get these defaults, but would be free to modify the node type as they see fit. project_review would also be responsible for tallying the votes for each project (probably in its own table of totals), and then exposing these totals to both views and solr so that you could do interesting sorts and facets for the project browsing pages. We could also enable comments on the review nodes themselves, to give people a chance to reply to the reviews in some way (e.g. someone writes a scathing review but didn't RTFM or something). This isn't central to the whole thing, but it seems like it might be useful to consider it as an option. Certainly easy to disable later if we don't like it. Not sure if we need it, but project_review.module could also be responsible for some trivial validation like the same user can't submit multiple reviews for the same version of the same project, etc. This could be added later if it turns out to be a problem. It'd probably also be worth exposing a default view that shows up as a tab on user/N/reviews that shows all the review nodes written by user N. A link to this view could be automagically appended to all reviews, so if you find a helpful review from someone, you can easily find any other reviews they have written. Project UI For now, the main changes to the project node UI for all of this would be: View of project_review nodes that takes the project ID as an argument, e.g. at node/N/reviews, perhaps just as a tab on the project nodes, or maybe its own page like the node/N/releases view. Block on the project node itself with the summary of ratings for each question and the total number of votes/reviews, with a link to a page for all reviews + ratings, and probably a link for "Rate this [project-type]". At the bottom of the project nodes, embed a view of the "top" review nodes -- i.e. the N highest voted (most helpful) reviews, and a "more reviews" link. There'd also need to be an "write a review" link that takes you to node/add/project-review/[project-short-name]. Project browsing UI The main download page and other project browsing pages in the redesign propose at least adding a sort for "Top rated" and for "Most reviewed". So, we'll just add those values to the solr document for project nodes, and then expose those as available sorts. If we really wanted to get fancy, we could expose each rating total separately, too, so that you could order by the highest rated projects under "well maintained" separately from the best documented, etc. We'll probably put all of those in the solr doc, although we might not expose all of them as available sorts and filters by default. Perhaps there will be an advanced search project finder page that lets you get crazy with all these options. VotingAPI? From my perspective, it doesn't look like VotingAPI actually helps us at all for the main project ratings: You want the voting UI while creating/editing a review node, not while viewing the project nodes themselves We already have a good storage mechanism for the votes -- CCK fields on the review nodes We're going to want some specialized logic for creating the weighted ranking values However, I'm not super familiar with Voting API, and I'm open to the possibility I'm totally wrong about this, and Voting API would save the day in various ways. So, I'm hoping someone more familiar with Voting API can comment here and either confirm that it's not really a good match for what we're proposing, or explain how it would fit in and what problems it would solve. Certainly Voting API + vote_up_down would make perfect sense for rating the reviews themselves ("was this review helpful?"). I'm just talking about if Voting API makes any sense for the main project ratings themselves, the questions I'm proposing we record via numeric CCK fields on the project_review nodes. That's the proposal. Please comment with any thoughts, concerns, corrections, or suggestions for improvement. After maybe a couple of weeks of gathering feedback, we'll move into implementation and hopefully roll this out on d.o in the near future. None of this is particularly rocket science. It should all be fairly straight forward to implement. Thanks! -Derek Drupal.org redesign implementers

---

Drupal Association Drupal.org Redesign Architect Employment type:  Contract Telecommute:  Allowed This will be an ongoing full-time contract (40 hours per week, or as agreed) for the duration of the redesign project. The contract is currently estimated to be 3 months in duration with the possibility of an extension. This is a contract telecommute position. Goal To communicate the architecture of the Drupal.org redesign to enable contributors to implement the redesign. Primary Responsibilities Understand, and document the entire existing Drupal.org infrastructure, and software architecture Review the prototypes and develop an architectural plan Document visually the relationships between the various components of Drupal.org (systems overview) Develop functional use cases and user stories for the redesign features and functions Create an element list with functional descriptions of the work to be implemented Document the implementation plan for each section so that volunteer implementation teams can complete their sections The above implementation plan and documentation should be completed within the first six weeks of being hired, and should include a high-level time line and level-of-work estimate for completion of the Minimum Viable Product (MVP). If the plan will take longer to complete, the Architect will communicate the reasons for the delay to the Board of the Drupal Association Liase with entire d.o. redesign team, including Infrastructure team, project module maintainers, implementers and project managers Work with the theme maintainers to ensure harmonization between theme and module development Manage the deployment of each redesign site and all sections Responsible for communicating regular updates on at least a bi-weekly basis to the entire project team, the Drupal Association and/or other designated representatives. These updates should document what progress has been made, what work remains to be done, what hurdles have been encountered, and how they impact the overall implementation plan. Be available in #drupal-infrastructure on IRC during established "office hours" and sprints Skills needed Drupal module and theme development Technical writing and communication Can effectively communicate with developers Required Experience Familiar with the Drupal.org environment An understanding of designing high-performace Drupal sites Experience managing complex projects with multiple teams Ability to effectively communicate and document project plans and specifications How to apply Please select the "Drupal.org and Git migration contract position applications" selection from the Drupal Association contact form, then submit a summary of your qualifications, along with a link to a .TXT, .PDF, or web page of your résumé, along with your rates. Experienced Drupal development companies as well as individuals are welcome to apply. Experienced Drupal development companies as well as individuals are welcome to apply. The Drupal association is a Belgian non-profit. The association is an equal opportunity employer and does not discriminate based on sexual orientation. Drupal.org redesign implementers

---

Would be great if the new Drupal.org can expose an api that allow for the following: retrieving the latest recommended release of drupal retrieving a list of modules retrieving an issue list on a module retrieving jobs retrieving events ... This would open up the door for loads of nice utilities that can assist Drupal developers. Drupal.org redesign plan for the Drupal Association

---

Drupal associaiton Fund raiser & community service manager Employment type:  Part time Telecommute:  Allowed The Drupal association is a non-profit organization which provides support for the Drupal, web content management, open source project. The Drupal association is an all volunteer organization with thirty permanent members, and a support base of over 1000 financial contributors. We will provide event sponsorship packages for the fund raising activity. You will also receive access to the Drupal association CRM, CiviCRM 2.1. As a fund raiser you will receive direct requests through the event website and be required to follow up via email and over the phone. This is a contract position. The association is looking for an experienced fund raiser to work part time. * Experience with creating fund raising plans and delivering regular reports on progress of those fund raising plans. * Excellent written and verbal communication skills * Experience with fund raising campaigns and selling sponsorship programs is preferred * Experience with CRMs, and newsletter mailings * Must have a mail client that can send emails with an alias, such as fundraising@drupal.org. e.g. Gmail. * Ability to work remotely, this is a telecommute position. You must have your own computer, internet connection, and phone system (e.g. Skype) for making long distance and International calls. Expenses will be re-imbursed. * Experience working with sponsors to deliver sponsors assets into marketing and advertising products. e.g. incorporating logos to banners * Experience with web based advertising delivery software. e.g. Google Ad manager * Knowledge of Drupal and open source communities is a significant asset * Written/Verbal knowledge of French or German is bonus Hours are flexible. Start date would be immediate. Initial contract length would be 6 weeks, and renewable going forward. Pay:$20-30/hour to begin, 20 hours a week. DrupalCon Paris 2009

---

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

---

As you may know, I spent a few months this year working with Mark Boulton and the Drupal community to try to make Drupal 7 (their upcoming release) a Great User Experience. I’ve spent the past weeks reflecting on that experience and trying to understand what we learned from that project and with any luck this will be the first of several reflective posts. It is all to easy to make excuses for why designing in an open source community can be tough. Certainly there are lots of communication challenges and we don’t necessarily have the right tools. Some people focus on the relationship between designers (minority) and developers (majority) in these communities – I think to do so is to focus on a symptom of the problem and not the cause. We faced many challenges with the D7UX project, but the greatest of all was to convince the community that the changes we were suggesting were actually going to result in an improvement to their project. There are many who steadfastly resisted our approach and who continue to do so. It would be very easy to take this personally and to argue about the details of the way the design works (and I most definitely include Information Architecture when I say design). This would also be a fairly typical Drupal thing to do. Actually, I think almost all the issues stem from a much more fundamental place – defining the real purpose of Drupal and it’s real primary target audience. From the very outset our goal with D7UX was to make Drupal more accessible to people outside of the Drupal community and less technical people – people who didn’t even know what PHP was let alone how to code it. Verity and Jeremy who emerged as part of this definition embody the target audience that the design work that Mark and I were doing in this project. This approach is representative of the goal to make Drupal more of a ‘product’ – an out of the box CMS solution that non-technical users can drive. This is key to the goal to increase the reach of Drupal, as Dries outlined in his keynote at the recent Drupalcon. There is one big problem with this approach, particularly if it touches the very core of Drupal. The changes that are required to the interface to really achieve the goal that we were tasked with – to really make Drupal understandable to Verity & Jeremy has the consequence of making Drupal a less efficient and enjoyable place for Drupal developers to build cool stuff. Drupal developers (and some designers!) who want to build cool things with Drupal are the core of the Drupal community. They are the people who make Drupal the incredibly vibrant community that it is. Without these people, Drupal becomes a shadow of it’s current self. These people are more than an important audience, they are the most important audience. What this audience wants is not Drupal as a product that Verity & Jeremy can use out of the box, they want a developer toolkit that gives them more and more flexibility and capability to build cool stuff, and to push Drupal way beyond the realms of a simple Content Management System. And so we have this tension. Drupal as a ‘Consumer Product’ and Drupal as a ‘Developer Framework’. Currently, the official direction is that the project is going to attempt to be both. I think this is a serious problem. The target audiences for each of these objectives are so far removed from each other in terms of their tasks & goals, their capabilities, their vocabulary, their priorities. An attempt to devise an interface to suit both will result in an outcome that I expect we’ll see in the release of Drupal 7 – that is a compromise to both parties. Verity is still going to need a lot of support to get anything done in Drupal 7. If Drupal 7 had been designed primarily as developer tool, it would be a much more focussed and efficient tool for developers. As it is now, it is hopefully an improvement on Drupal 6, but certainly not the best that it could be for developers. For Drupal to really succeed, a decision has to be made, and I think there is only one decision that can be made. Drupal 8 should be designed with developers as the primary target audience and the language, tools, interface should be designed to support them in their goals of building really amazing stuff using Drupal. That doesn’t mean that there is not still a lot of work for the User Experience people in the Drupal community to do – there is still an enormous learning curve even for those new to Drupal who have great PHP and other technical skills. It’s going to be much easier to address that learning curve with a more finely targeted audience in mind – or more importantly, with the right target audience in mind. So what of Verity & Jeremy? How will they ever come to know and love Drupal? There are a number of ways that we can address the experience of non-technical users of Drupal and to ‘productise’ Drupal as a content management system. The most obvious is to design and develop an admin theme that is specifically targeted at these end users that can be applied by developers once the development work is done and the site is being handed over for administration. I’m not sure where the incentive to design and develop this theme comes from (given that it doesn’t exist today it strikes me that there is a problem here incentive-wise). There are also opportunities to be explored with installation profiles (see above though re: the fact that they don’t really exist now and no one seems motivated to work on them, where is the incentive?). And, of course, we have the emergence of tools such as Buzzr from Lullabot and Gardens from Acquia, perhaps also products like Open Atrium from Development Seed can included in this list. A tough decision but a necessary one I know that for many people the idea of making a Drupal that Verity can love, making something that can actively compete from a UX perspective with the likes of WordPress, is a grand aspiration. So it is, but unfortunately I also think it is the wrong aspiration for Drupal core. The sooner we focus on the core target audience of Drupal core – the developers – and commit to making a user experience that supports them in their use of Drupal, the sooner we’ll really have actually achieved a really Great User Experience for Drupal. If that is really our goal, then let’s get focussed, let’s re-write the design strategy and principles, and let’s take the work we’ve done already and refocus it more tightly on the community we know and love. Focussing on the strength of Drupal and then looking for new and innovative ways to create and motivate the Drupal community to do a better job of looking after our Verity’s and our Jeremy’s.

---

I would like to see a hiearchical view of modules, that require dependencies, both in images of the actual module on its page, and also in the URI/URL. It cements the idea I have of it, if you know what I mean. A lot of modules are listed as living in ether, and are middleware for views or another module. At the moment the projects section is quite difficult to traverse. Could it be possible to maintain it with either just a block that lists its dependancies, and which modules require it? This would organise it so that in order to create an installation or a profile, that does one thing, a person/programmer could grab at one tree of modules, and not waste time looking at the whole kaboodle, going wow it does this or that.. and instead go okay, today I am creating with that 'treemodule'. This also gives an impression of finding what possibilities there are from the start, with this CMF thing. I didn't realise there was any genealogy stuff here, but I would have known sooner if there were fewer base modules to glean functionality from. Helper functions can be listed as CRUD base modules, for instance, unless you want to rename that as HUDBF, i.e. Helper (User) Drupal Base Functions, or even something that rolls off the tongue better. Essentially, this create a few extra fields for each modules submission, dependancy (1,2,3,..), required by (1,2,3,..). The moduletree module would compile all it sees, when people click on projects, and it would display, in context, the module, and its close ties. Okay, so it might run into problems when 200 modules require this one, but it would in this circumstance show what is popular, and most used/required. The stats from something like this would be rather interesting. When there are more than one galleries, it may cause problems, but then, I guess this would invlove putting a horizontal view together with the vertical view. It might be interesting to see a link to another page of this picture/view, or even a small banner above the content, or even a tab with these details. It would also be nice to see examples, for instacne to show organc groups as being simialr to alt.newsgroup design/structure. So another block/tab would have similarites. In some pages there are usages and features, but that is only down to the module author to instance these, whereas if authors had to populate these fields, they might put something other in than n/a, which of course would not show, it being part of an if statement, i.e. if n/a then dont show endif. I did not associate organic groups with newsgroup functionality, and was quite confused about whether I needed it until that is I delved deeper. It took me too long to find out what it was, and I really did waste a lot of time. Drupal has many many modules, and I really dont need to waste months going through modules until I find the right ones to build a site. Its just not feasible, and from a design pov it does not make drupal accessible. I understand that it would be very dificult to start redesigning the whole site, telling authors they need to populate these fields, so you could instead just introduce it as a part of D7, when its roled out for this site g.d.o and/or d.o. In a way this is partially represented in the Beyond The Basics block, for instance the Videos and Slides menu item has child item Modules, which iself has children. This, for me, is a bit confusing, seeing as there are a few items with video in the title, which could all be children of media instead of Videos and slides. Although with the beyond the basics module, it would be nice to find things which are specific to my version of drupal, i.e. D6, and not have to wade through them all, or if it is for D5, which automatically makes it for D6 then it should say that, as modules are not crossversionable, so why should howto's. It seems a bit jumbled all together for me, but then maybe I am a special needs case, or maybe I am an average user. I'm certainly no programmer, although I know my php's from my asp's. Enough of me. What does everyone else think? Does this rattle a few bones, produce a few hums, or maybe just brings out a few blank stares? Thank you in advance. Building Site Traffic

---

The best way to a good end user experience is a program of iterative testing and design. There’s been quite a lot of design but not as much iteration as we’d have liked, so now is a good time to really kick off some testing of the D7 interface as it comes into existence so that we can potentially iterate it a little before it is set loose on the unsuspecting public. In order to take best advantage of the enthusiasm within the community to participate in testing we should ensure that we are taking a generally consistent approach to the test process so that we can better compare our results and make decisions more easily. A way that anyone who wants to can conduct some tests and provide feedback, insight and recommendations, no matter where they are in the world, in a way that we can actually act upon. Here are some initial thoughts on a framework for testing the D7 interface that can be adopted by anyone within or outside of the community and around the world. Making use of previous usability test framework: The Drupal Usability group conducted formal usability testing in Baltimore in 2009 (ref: http://drupal.org/usability-test-university-baltimore-community-solutions) which has informed much of the UX work that has been undertaken over recent months. It makes sense to capitalise on this previous effort as far as possible, not only to reduce workload at this point but also because it will provide a useful benchmark. There are some areas where it is appropriate to make some amendments to the approach taken in the Baltimore testing, these will be discussed below. Target Audience/Recruitment: As with the Baltimore approach, our testing should target two specific user groups who are important to achieving increased ‘reach’ for Drupal, and who have been at the heart of the D7UX design effort. Baltimore identified these groups as ‘Beginner’ and ‘Intermediate’. This assumes that every end user is at some point on the same Drupal learning curve, which our research has shown not to be the case – this is demonstrated in the example users identified in ‘Who Is D7UX for’ (http://www.d7ux.org/who-is-d7ux-for/), where the users Verity and Jeremy are described. Verity would equate most closely to the ‘Beginner’ audience used in the Baltimore testing, however the description of ‘Beginners’ it was specified that these people have some development experience, and the script implies that their role may involved building a website using Drupal. Verity, on the other hand, is the recipient end user of a Drupal site who is then tasks with maintaining the content on that website. This is a very typical end user role for Drupal and one which we hope that Drupal 7 will do a much better job of supporting. Jeremy, however is quite a good fit for the Intermediate audience group recruited in Baltimore, although again, development skills should not be required in order for him to successfully complete the tasks in his test script. I propose that went we are recruiting people to participate in our user research we compare them to the Verity & Jeremy sketches and if they are similar, they are good matches for testing. Depending on which they match, we will then use a discussion guide and set of tasks tailored to their role and objectives. Discussion Guide/Script: The scenario presented in the Baltimore testing was essentially to build and/or manage content on ‘a website for a conference where users will post information about the conference like the schedule, speaker bios and local bars’. This is a great scenario and is suitable for both our Verity and our Jeremy participants and I suggest that we re-use this scenario, the content materials prepared to support the scenario and used in the test, and as far as possible, the script that was devised for the previous round of testing. The existing beginner script is, I think, almost entirely suitable for the Verity role, and comprises the following tasks: publish some information about the conference (to existing content types/sections of the site) taking content from a text file provided. create a navigation link (if we leave anything out of this script, I think this might be it… not sure if this is a real Verity task… could be tho’) change the look of your site, remove the logo at the top left creating a new role (speaker) with additional permissions (suggest that perhaps rather than creating a new role, assigning users to a the speaker role might be more appropriate for Verity) create a new page (schedule) and navigation to that page The existing Intermediate script is also very suitable for Jeremy, and comprises the following tasks: installing drupal publishing some content about the conference to the site creating navigation creating a new role (speaker) with additional permissions using taxonomy to categories ‘workshops’ using a block to highlight content on every page of the site customising the URL of a particular page allowing speaker role to use images in their content creation set up site search There may be some additional tasks that we want to include, however these scripts are already quite lengthy so perhaps it is best to prioritise tasks and we can iterate the script over time as more testing is completed, to increase task coverage. Test Materials (What to test on) I think this is the biggest challenge, especially in the case of Verity, and it’s not something for which I have an immediate solution. Here’s the problem – it is not reasonable to expect Verity to be able to perform the tasks outlined above using a straight Garland Drupal website, and it is not a reasonably approximation to the reality of this end user. Garland looks far to much like Drupal and far to little like a contemporary and designed website. It introduces a raft of challenges to understanding the interface that Verity would never have to address in using the Seven admin theme over the top of a professionally designed website. We need a theme for testing, however simple, that looks like a proper, designed website. And, in the case of Verity, we need a little structure and content already in place on the website. Now, there are dozens and dozens of Drupalcamp websites out there… is there some way we can get one of those approximated in Drupal 7 in a reasonably short timeframe? Ideally, Jeremy will have a theme other than Garland as his default Drupal 7 theme also. But, for me, this is less problematic compared to Verity. Help! Reporting Findings & Making Decisions Our testing needs to be video recorded (screencast) – I’ll be using Silverback (because it’s cheap and I use a Mac) but there are many other solutions out there. In order for our findings and recommendations to be agreed and accepted it is important that we’re all able to check back to the source. There is a Drupal UX Group on Vimeo (http://vimeo.com/groups/drupalux) which seems like the logical place to post these videos (to avoid the 10 minute rule on YouTube if nothing else) and it also makes sense to utilise the existing drupalusability.org infrastructure for reporting findings although it will need to be reworked to allow for the ‘crowdsourced’ and iterative nature of this test approach. Next Steps Assuming we agree that this is a good way forward, then there are three key tasks that have to be completed: a) we need to finalise scripts and make them available to people who wish to conduct testing b) we need to resolve the issue re: a testing theme, and c) we need to ensure that drupalusability.org is ready to receive feedback from multiple sources I know that within the UK there are at least two groups who are keen to make a start on doing some testing before the end of September. It would be great to have this framework in place so that we can make the best possible use of their time and expertise, so, time (as ever) is of the essence. What do you think? Sound good? Can you help?!

---

Drupal/Economist Project – Sprint 2 Demo from Leisa on Vimeo. Today is Demo Day at The Economist, where all the various SCRUM teams will show and tell what they’ve achieved in their latest iteration. I thought I might see if I can get into the habit of pre-recording my demo so I can share it with you here and ask for feedback & advice! So, here we go! In the past two iterations (this project runs on 1 week iterations) we’ve done a combination of research, design and testing the publishing tools that the editorials staff will use to administer what is known as the ‘Channel Index Pages’ – these are pages that you’d land on if you clicked something in the navigation that said, say, Business & Finance, or Science & Technology, and their job is to pull the most interesting current content to the top so that readers can access it more easily. These pages are made up of a range of elements, most importantly for this demo are News Packages (consisting of a lead story and related stories/media files) and what is known as the Bloggy Chunk (an editable text area that section editors can freely input their own content, it is still very much a work in progress and is variously used as an aggregator for recent interesting stories that The Economist isn’t covering in depth or to highlight interesting reader comments, it may in the future show content from an RSS feed). Although working within the SCRUM methodology, I am trying to take a systemwide approach to the design as far as possible, so there has been a whole range of questions that I’ve had to consider that aren’t strictly in the ‘stories’ for our sprint (logging on, activating editing, for example), and similarly, I’ve tried to devise interaction approaches that will be reusable across the other parts of the system that we have yet to design rather than just customising the design approach to this individual problem set. The design approach shown in this demo is still quite lo-fidelity and ‘broad brushstroke’, it will become much more precise over time, at the moment my priority is to try to work through and communicate the ideas as quickly as possible – giving me more time to explore a range of approaches, and to iterate approaches which has been very valuable. So, if you have a moment and are so inclined, I’d really love to get your thoughts on the approach we’re taking so far. We’re also about to embark on starting some development work on this – to make sure we can build it in Drupal without too much difficulty – so if anyone has any guidance on how best to approach this, modules we should take a look at, anything else you think we might need to know, I’d love if you could share it here! Look forward to hearing from you and thanks in advance! (apologies to anyone who saw the first version of this blogpost with the screwy audio synching)

---

Infrastructure: Development/testing instances (Discussion in Infrastructure Requirements) We are still hamstrung by the lack of dev/testing instances. What we need from dev/testing instances A test instance that the public can view and click around on. This will help us build interest and momentum. Several dev instances (at least 5) split between developers and themers. Nice to have: Script to roll out new instances on the fly Sanitized DB for remote and local dev instances. Should be easily downloadable for those who want to set up local dev instances. User 1's username and password should be pre-reset. Nice to have: Script to clone a canonical, sanitized DB into remote dev instances as needed. Apache Solr needs to be set up. Next steps Contact Damien to see if he can help plan and delegate infrastructure tasks. Find additional infrastructure team members to help set up dev/testing instances. Talk to David Strauss about Capistrano to manage scripts that automate various tasks (like dev instance rollouts and DB cloning). Settle on a file-storing service for theme assets and move assets out of SVN. We are currently leaning towards Wuala. Create a guide to getting started We need a comprehensive guide to getting started. There are a number of posts in this group that contain elements of this guide; we need to compile and expand on them. What a "getting started" guide needs How to work with a dev instance (both local and remote) Using SVN How to set up a local dev instance Using MAMP or other local dev environments Checking out the drupal.org redesign branch locally Setting up clean install Importing d.o database where to download database importing database How to keep up with the project: notifications, RSS, issue queue, etc Asset management How to find things to do prototype Communication with volunteers Send a link to the "getting started" guide. Explain the situation with the dev/testing instances. Emphasize that work can still be completed without a remote dev instance. Enumerate what our plans will be once this is completed. Communication with volunteers who already have SVN access Set up times for local dev "installfests." Find Linux and Mac experts willing to troubleshoot. Use Doodle to arrange convenient times. Gauge interest in creating and distributing Linux virtual machines. Communication with designers Send a designer-only email that omits all the technical details. This email should contain only information on MB's prototypes, remaining design tasks, and links to the assets file-storing service. Other remaining tasks Kathleen is working on digesting all literature and issues related to the redesign. She will then conduct a site audit to determine what remains to be done. Ensure new drupal.org functionality has been ported to the drupal.org redesign branch. Establish a procedure for porting changes between branches. Drupal.org redesign implementers

---

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: Understanding the D7UX Information Architecture Approach (with thanks to @royscholten) http://bit.ly/1Yce76

---

Drupal.org Drupal Re-design infrastructure manager [Manager] Employment type:  Part time Telecommute:  Allowed The Drupal redesign needs several infrastructure managers to help manage testing sites for redesign themers and redesign developers. A Virtual Machine will be provided to the infrastructure managers. You will be given access to recent copies of scrubbed database copies of Drupal.org. Duties will include: 1) Approving SVN Accounts for themers and developers to the private theme and drupal.org code repositories. 2) Creating new drupal.org instances for themers to work on. 3) Pushing theme and code changes from SVN To learn more, see: http://groups.drupal.org/node/23645 Drupal.org redesign implementers

---

We need to discuss how we want the d.o redesign project to move forward. One- to 5-day sprints every few months is not a sustainable solution. Maintaining momentum and continuity is nearly impossible. Initial thoughts: Take a cue from the Aegir project and introduce a proper schedule Require weekly time commitments and weekly meetings Initial thoughts: 4 hours per week for at least three out of every four weeks (meaning you can skip one week from every four to catch up on client work) Find a proper Project Manager -- not a designer/themer/developer willing to take the role of PM May require hiring a part-time PM We need a dedicated and managed development environment. Having to download, pass around, and import DB dumps can easily eat up half a day or more, and we need a place where people can publicly view or test our work. Drupal.org redesign implementers

---

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: A review of D7UX brainstorming in London last week (thanks @jeffnoyes) http://tinyurl.com/c8febv #d7ux

---

drupalredesign: if you're following the #drupal7ux tag you might want to switch to #d7ux - seems to have evolved as the preferred tag. Sorry about that!

---

drupalredesign: check out the new project framework to aggregate discussion incl. an initial UI aesthetic approach http://www.d7ux.org/project-framework/

---

drupalredesign: Drupal 7 UX - Initial Concepts & Direction. http://tinyurl.com/c45xs8 #drupal7ux

---

drupalredesign: we love paper prototyping at the start of a project. want to know why? http://www.d7ux.org/d7ux-process-update/ #drupal7ux

---

drupalredesign: we have principles! design principles no less. check them out here: http://tinyurl.com/cxdblw #drupal7ux

---

drupalredesign: Crowdsourced Usability Testing Rnd 1 - Investigating Information Architecture - http://bit.ly/14JVqX #drupal7ux

---

drupalredesign: with thanks to everyone who gave feedback on Version 1, Version 2 of the #Drupal7UX Experience Strategy for your review: http://is.gd/pTax

---

drupalredesign: help us test D7UX, get involved in our crowdsourced usability testing project: http://tinyurl.com/dfgkux

---

drupalredesign: D7UX - a mudmap of our quasi-planned project process: http://is.gd/pEYe #drupal7ux

---

drupalredesign: For those wondering why so much of the Drupal UX project is being run off a Wordpress Blog - http://is.gd/pDkK #drupal7ux #d4d

---

drupalredesign: how does Drupal talk? Take our personality quiz :) http://tinyurl.com/cy6wbo #drupal7ux

---

drupalredesign: welcome new followers to the D7UX team - so happy to have you all aboard! First exercise coming up! (as soon as YouTube is done processing)

---

drupalredesign: posting a whole stack of Drupal7 work in progress and half baked ideas to Flickr http://is.gd/p4Jd #drupal7ux #drupalusability

---

drupalredesign: We Need You! Get involved NOW (not next week!) help make the Drupal7 UX a *great* UX. http://is.gd/p3lH #drupalusability

---

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

---