Post Drupalcon Portland discussion

Thread moved from Gmail

Lisa Rex

Tue, May 28, 2013 at 4:19 PM

Hi,

A handful of people attended the BoF at at Drupalcon Portland (from this group was Dharmesh, Michael and I) to talk about ways to drive UX improvements (notably usability studies) amongst the volunteer community and identify areas that needed UX attention. From that group, several more folks sprinted with me on Friday, and we created this wiki and as well as coached some moderators through the content creation UX study that was written up for Portland. http://groups.drupal.org/node/300203 

Per Thomas' comment on the wiki, I def agree that a more collaborative / holistic approach would be better. 

The only suggestion I have at the moment is to increasing the 'every other Monday UX meetings' to every Monday for the duration of the D8 release cycle. We can try to do every other meeting in a conference call since Google+ hangout didn't work very well last time. The old 'IRC is hard / weird' is at the front of my mind.

What are folks thoughts on increasing frequency? 

Also, Thomas, you mentioned you were having a BoF at Drupalcamp last weekend to discuss similar topics. What was the outcome of that?

---

Bojhan Somers

Hey Lisa,

I think discussing these notes is very useful, during a UX meeting we could definitely tackle the holistic concerns he has. I think there is some confusion over intend and power that we have in executing strategy, which are two very different things, but could easily be confused. 

We did have weekly meetings, sadly its pretty common for meetings to only have 2-3 people in attendance, increasing this could help or not. I certainly won't be able to make all meetings. I wouldn't mind more meetings, but this means people on the team will need to take up this role. 

Although I know there is much love for the Google hangout format, I still feel little for it - perhaps thats because I am a non-native speaker, being more able to express myself in writing. We have kept the IRC format, because its open to others in the community - the non-UX kind, who are key to our existence and helps invite them in when needed. 

Regards,

Bojhan

---

Kevin Oleary

Tue, May 28, 2013 at 6:22 PM

To:
Lisa Rex

Thanks Lisa,

Would have gone but it was opposite my session. I totally agree on increasing to every Monday.

-Kevin

---

Thomas Svenson

Wed, May 29, 2013 at 5:51 AM

To:
Lisa Rex

Hey Lisa and gang,



Our DrupalCamp here in Gothenburg last weekend was excellent and the
BoF discussion very fruitful. It actually only indirectly touched on
UX as our focus was about how to get more in-person local community
happening. We have a none existing such thing in Sweden today and,
despite Sweden as a whole has always been on the tech bleeding edge
forefront, there are few active Swedish Drupal users within the
global community. That to me is quite strange and remarkable.



In the BoF we discussed ways to change that, how we can meet, talk
and work on Drupal, contributed projects, learn from each other and
so on. It is in there UX will be a part as everyone agreed that
meeting and discussing with people that has different skills is a
good thing.



I also had many awesome discussions touching on UX with attendees.
Many even came up to me asking about it. People are getting more
curious about the stuff I have been blogging and annoying people
about on d.o. It was very rewarding when I was treated to smiles of
understanding when I explained UX in ways that related to what they
do. Some even came back a little later, having thought it over, and
wanted to hear if they got it right. That made me feel very good I
can tell.



As I mentioned in my comment to Lisa's g.d.o wiki, I don't believe
usability studies is going to be very helpful. They will just
confirm the problems we already know. Yes, smaller things might be
possible to address and get some form of fix, hack, in for. But to
fix the underlying problems is simply not possible, there is no time
for that. The only way we ever going to see a real and solid UX
improvement in Drupal, and contrib, is by finding ways to make UX
design part of the process from the start, not tacked on at the end
after code is already written.



In Munich I spoke with several core initiative leads and the
sessions from Portland I have seen so far has reaffirmed that the UI
is something that is done late in the development. Basically that
means the UI has to be adapted to the functionality of the code
logic and the API's. In other words, the UI is created and
adapted for the machine and not the human users. This also
includes the workflows for user roles dealing with various parts of
Drupal, from installing it to visiting a Drupal site as an anonymous
visitor.



UX then isn't helping to drive the development as the whole process
- it is done backwards. It is because of this backward process we
have ended up with these Limitations and Bottlenecks. Often
leading do a pogo-sticking madness really.



The next big UX issue we have is that Drupal lack a consistency when
it comes to the UI look and feel. Yes, things are improving in D8,
but from what I have seen the various core initiatives, as well as
many other smaller and bigger core pieces, there is very little
collaboration about creating a consistent UX. Yes, inspiration and
influences are picked up when people gets a peek at what others are
doing, but much of the implementation is done based on the
initiatives and/or maintainers own interpretation of the needed UI
for their isolated functionality.



These for me is what is the foundation to why the Drupal learning
curve is what it is and it is also the root to that Drupal is
getting unnecessary complex.



It is also what sadly inspired me to write - Don’t
Make Drupal the New ‘Microsoft Office’!



We wont be able to change this with more small group isolated UX
meetings. Particularly if we don't first develop a solid strategy
for how to:

• be able to create real awareness about what UX is and how it
  can help improve Drupal
• how to make that happen
• how to provide role tailored basic UX training
  

We have particularly failed when it comes to education and
training. I am not talking about creating an army of UX experts
here, far from it. The goal with the training part must be to
provide relevant training that gives members of the community
basic UX understanding that fits with their current roles. UX is a
fundamentally different skill compared to what is needed to be a
great code developer for example. Done right, I am convinced they
then want to continue to want to learn more about UX.

A good code developer armed with basic UX skills that helps them
to earlier identify what risk to become UX problems later will
quickly transform into a great code developer. One that will be
able to better predict the functional requirements. This will also
lead to a much more fruitful collaboration between various roles,
including allowing UX experts to participate earlier in the
process. They wont hesitate to contact UX experts when they see
the need for it!

I'm sure most of you have heard the saying about the difference
between giving a man a fish or teach the same man to fish.

Well, that is how I see how we have done much of the UX in
Drupal. We have given out the UX fish to other roles and told them
to eat it. Fishes many of them never seen before, don't know if
they will like the taste of and ones they are afraid will poison
(waste) their time... It hasn't really worked that well. Thus I
say its time to see how we can teach at least basic UX fishing
skills instead.

After all, Drupal developers love hooks - Lets give it to them!

/thomas

---

Lewis Nyman

Wed, May 29, 2013 at 6:01 AM

To:
Kevin Oleary

Keeping UX events regular is good, it also needs to be ‘promoted’ correctly. Every Monday sounds simple, but when everyone has many meetings or commitments going on in a week it's easy to forget. We need to make it hard to forget.

I think there's a lot to learn from the organisation of the D8 initiatives on maintaining regular interest over time. The mobile initiative meetings have been working well with Google+ because the event promotion (email invite), event sign up (google cal), and event reminders (hangout invitations) are all integrated into the one tool. I think posting the events on g.d.o is a good way to hook new attendees but it doesn't do a lot for regular attendees. The mobile initiative is a hangout broadcast over youtube combined with IRC chat for questions.

On Thomas' point about overall UX in the Drupal process, I think equipping developers with the right tools to create more usable interfaces is an important task, we can't advise every contrib module and nor would developers want us to. I think a style guide, well documented, is a good start. I think expanding on it over time to incorporate more components, test cases, and flows, will give developers a good foothold. Brad Frost's presentation on Atomic Design is compelling.

Right now were so pressured into getting the new design into D8 that the style guide hasn't received enough love, I'd really like to change that soon.

Terrence Kevin OLeary

Wed, May 29, 2013 at 9:49 AM

To:
Thomas Svenson

Hi Thomas,

Thanks for the detailed recap. I especially liked this quote: 

"The only way we ever going to see a real and solid UX improvement in Drupal, and contrib, is by finding ways to make UX design part of the process from the start, not tacked on at the end after code is already written."

I made this same point several times in Portland as did Dharmesh and Preston in their session on iterative prototyping and testing.

The possibility we discussed is that we establish a design issue in the issue queue. This would have a different type of flow from a bug or a task and it would separate the process of design from the process of implementation (which is, I think the same goal you have).

The design issue queue would look something like this:

1. Issue starts from a design problem that arises in another issue or comes out of user testing 
2. Create a design that solves the problem and post sketches, wireframes etc. to the queue for discussion (no implementation comments allowed)
3. Revise to Incorporate feedback repost for comment (if needed)
   
4. Prototype in HTML/invision/axure
   
5. Usability test. If the test is fail start again from #1. If the test is a partial success revise and re-test. If the test is a success move the issue into the implementation queue.

If once the issue is in implementation, if at any point there is a design blocker (design can't be built as designed) design goes back to design queue with a detailed description of why it cant be built as designed. Design does *not* get revised in the implementation queue. If it can't be built as designed it *always* goes back to the design queue. This way usability results don't get watered down and designers are educated about the constraints of the system (and encouraged to push those boundaries).

---

Terrence Kevin OLeary

Wed, May 29, 2013 at 9:50 AM

To:
Lewis Nyman

Totally agree on all points.

---

Roy Scholten

Wed, May 29, 2013 at 4:40 PM

To:
Terrence Kevin OLeary

Some of my thoughts below. Posted them as a comment to https://groups.drupal.org/
node/300203#comment-929978 as well, which is where we should be having this discussion anyway :-)

Roy



Good to hear some more perspectives. Mine:

1. Any holistic approach is for Drupal 9. Starting now :)
   

   2. Any holistic vision has to also be expressed in strategies which then need actionable tactics in order to move towards the vision. Without the other parts the vision remains only that. Strategy is in the delivery, it has to go beyond words.
   

   3. Our main bottleneck has always been and still is a lack of (reliable) resources. This is not unique to the UX corner of Drupal, but we're much smaller in numbers than the development teams, so we feel it more directly.
   

   4. It's also why a design-first approach will not fly. If we're 1 designer for every 100 developers, do you really think the latter will wait until the first are done designing? The Drupal project doesn't need more bottlenecks.
   

   5. What would be useful I think is to indeed start strategizing, learn from the initiative leads and their process and set a UX agenda for D9. We kind of did for D8 as well, but hey, lack of resources etc…
   
   

   For Drupal 8:
   
   

   1. Lets set some priorities in what needs work in D8UX
   

   2. Or: What would we do if we had a full week to do a UX sprint?
   3. Use Dublin dev days and Drupalcon Prague to our advantage in moving those forward

4. Educating devs on UX basics is key. Focus on this when contrib is porting to D8

5. Help people start chipping away at small things. Setup new UX folk to be succesful. Small tasks, small victories etc.

Next monday UX meeting in IRC, #drupal-usability. Be there :

Again, https://groups.drupal.org/node/300203#comment-929978 is the better place to discuss.

---

Thomas Svenson

Fri, May 31, 2013 at 5:35 AM

To: Terrence Kevin OLeary

<

p>
Hey all,



@Kevin and @Lewis,



Thanks for the nice feedback on my thoughts. Good to hear others
have made the same observations, particularly in regards to the
training needs.



Yes, I agree that we somehow need a better way to identify and
perform UX work in the issue queue, it was also something that
Michael and I had in mind when we worked on our DrupalCon session.
See
http://www.tsvenson.com/blog/2013/05/our-drupal-workplace-the-issue-queue
and the recording is embedded there.



However, I am not so sure that starting with mockups, sketches and
UI designs is the right thing, A very common misunderstanding about
UX is that many believe UX = UI. Yes, UI design is very important,
but we need to somehow show that UI design is a result of UX design
and happens after that. It doesn't really matter how well a form is
layed out or how pretty the visuals look if the workflow and
interaction with it isn't working.



What I have found to work the best is to give good use cases to
illustrate bad UX. By walking others through scenarios where the
existing and/or proposed functionality is used it is much easier to
give for example code developers an easier way to understand the
problems we identify. Epics and User stories in agile development is
very similar, but surprisingly those aren't really identified as UX
tools?!



Having a bunch of good use cases will also greatly enhance the value
of the UI designs. It will be easier for everyone to visualize how
that UI is going to work when you have a few good examples to apply
on them.



The main challenge we have here, particularly for the issue queue,
is that both the use cases and the UI designs always looks at things
on a much broader perspective, it involves workflows and often many
different technologies, parts of core as well as several contributed
modules. That while issues are trying to deal with as small and
isolated tasks as possible.



Somehow we need to find a way where those two objectives can work
well together.



/thomas

---

Thomas Svenson

Fri, May 31, 2013 at 6:43 AM

To: Roy Scholten

@Roy,

<

p>
How come we can't just admit that thus far the current methods used
to address the UX situation in Drupal hasn't been very successful?

4. It's also why a design-first approach
will not fly. If we're 1 designer for every 100 developers, do you
really think the latter will wait until the first are done
designing? The Drupal project doesn't need more bottlenecks.

Exactly and still this how much of the UX work in the community is
being done. That is what I mean by giving away fishes for others to
eat, others who don't even like fishes. It is also the main reason
to my Michael and I took the initiative to Drupal SBUI. An
initiative we presented to you and had several at length discussion
about.



This is not a Drupal 8, 9, 10 or XYZ problem, its a Drupal community
problem. We also know from experience that what has been tried thus
far hasn't changed much. We who are passionate about UX are still
quite understood in the community and many see us as creating more
work that takes focus from code writing and delaying getting the
next Drupal out.



Sorry for being a bit harsh here, but as long as we try to fix UX by
trying to adapt it to the current common development process we are
not going to see much improvement. That model is write the code and
functionality first, then figure out how to squeeze in some workflow
and design a UI on-top of that...



We need to find good arguments and examples to show just how
backwards that process is. That it is actually what has made the
Drupal learning curve so steep, that it is creating more work for
code developers, that it is adding unnecessary complexity to Drupal.
Lastly, that it is actually making Drupal less flexible and less
future proof as a result.



An excellent example for this is the file cleanup implementation
that was introduced with Drupal 7. Basically a use count was added
for files uploaded. Then when that use count gets to zero Drupal
automatically deletes the file. There is no warning or notification
for users. The file is silently deleted. This basically is a UX
black hole. Particularly as there is no configuration option for
turning this of in D7, nor any good API to change this behavior with
a contrib module.



The latest attempt to fix this for D8 is in the
https://drupal.org/node/1399846 issue.



This issue encapsulates perfectly the level of awareness of UX needs
in the Drupal community.



All the pain and added work, thousands of hours of spent, trying to
fix the damage could have been avoided if even the most basic UX
principles had been applied before the first line of code for this
got written.



The idea behind this cleanup functionality is so simple it would
have taken tops 10-15 minutes to describe the purpose and how it
would work. But for UX people like us it would have been enough to
quickly identify an write several very good use cases from. Use
cases that would have demonstrated clear risks and flat out dangers
with it. An example of such use case is the one I made in
https://drupal.org/node/

1399846#comment-7468280.



It is that level we need to start and where we have the best change
to raise awareness about the UX needs. Here we can easily show the
value of UX and how it has the potential to save tons and tons of
time and headache for developers too.



Regarding the Monday UX meetings. What is the purpose of those? What
is the agenda and goals for each meeting?



I have very limited time to volunteer to the community as things are
at the moment and need to know I can use it effectively.



/thomas

---

Bojhan Somers

Fri, May 31, 2013 at 7:09 AM

To: Thomas Svenson

<

p>@Thomas I really advise you join the meeting of next week, to discuss things. I appreciate all the work you are putting into these e-mails, but as suggested it is much better to have this topic as a conversation for a meeting and/or the appropriate g.d.o thread. 

Lets not have this discussion in a closed medium, we are not the only forces at play here and I am worried a lot of the valuable feedback here will get lost, because its not online and its not with other community members.

---

Ps. If anyone wants to know how to move a gmail thread to a wiki let me know and I'll write it up

-Kevin

Michael Keara

There are lot of excellent, and seemingly diverse, points raised by everyone. I think they represent the key touch points associated with the (mammoth) task of improving the Drupal UX. This is what I’m hearing:

• Discussion around meeting formats that work/don’t work
• Discussion around training developers and making effective use of limited UX (and developer) resources
• Discussion around process – ‘design-first’, ‘holistic approach’, UX strategy
• Discussion around immediate D8 activities (testing and fixing) versus longer term D9 planning and preparation

My perspective is shaped around a primary focus on UX strategy and this is how I see the parts coming together.

I agree with Roy that UX strategy is needed as we move into the D9 phase. Roy says we ‘kind of’ did that for D8. However, speaking frankly, I don’t believe we really pulled that off in an effective manner. At his keynote in Denver, Dries proposed that we spend April and May doing UX analysis and then June and July focusing on design. Roy and I led a very fruitful ‘double-BoF’ at Denver that focused on important, high-level questions around defining ‘context’ and ‘pages’ that we recognized as central to this analysis. Some good discussions came from this on D.O such as:

• March 20, 2012 Drupalcon BOF "Context" User Stories
• March 20, 2012 Drupalcon BOF, Semantics: What is a 'page'?

I also added some other discussion threads that were titled with the prefix ‘D8 UX Analysis’

• D8 UX Analysis: Design Assumptions and Principles
• D8 UX Analysis – Layouts, IA Spaces and the Principle of Definition-Usage Pairs
• D8 UX Analysis – The IA Space Hypothesis

While there were some good responses to one of these threads, I think many of the questions posed there still need to be answered. Perhaps we can do that in the D9 cycle.

In my opinion we went into D8 without a complete analysis and I think this left us without sufficient tools to get the design job done. Without analysis we cannot arrive at a UX strategy. Without UX strategy we cannot produce effective UX designs. Without effective UX designs we cannot produce systematic and successful UI designs. And without all of these things our job as UX designers is significantly harder.

As far as I can tell there is no structured place for UX strategy discussions. For the most part, IRC and even the Issue Queue are tactical tools. If you watch the presentation about the Issue Queue that we prepared for Portland, you’ll hear Thomas and me pointing out the ways that the community loses enormous amounts of energy because of obstacles in the Issue Queues workflow. I think aspects of that are reflected in this discussion. As a UX strategist, I simply cannot communicate effectively anything of value in the IRC – at least not at this point in time. UX Strategic discussions require more structured meetings – perhaps even with an agenda and a moderator and prepared presentations. That suggests Google Hangouts to me (as much as I have had difficulty using that technology in the past).

That’s why I’m very happy to hear Roy talking about the need for UX strategy. And I’m very happy to have had a chance to collaborate with Thomas on the Site Building Usability Initiative (still in its infancy but aimed at Drupal 9) because I agree that the Site Builder Role is so central to the entire process that resolving those issues forces one to arrive at a strategic perspective. (For more thoughts about that you might want also check my Drupalcamp Toronto presentation Snatching Usability from the Jaws of Drupal .)

I hope we can organize an effective forum for this type of discussion. I think the larger Drupal community needs us to do this - and pretty soon. I believe we are at a critical turning point – not just in the Drupal evolution but also in the evolution of the web. I think Karen MacGrane’s keynote in Portland underscores this idea and she has challenged us (the community) to rise to the occasion.

I know we can do that. But to do so, we’ll really need to have our UX strategy chops down. We need to balance out the established practice of tactical methods for approaching UX design with communication tools that can support the ‘holistic approach’. I look forward to sharing more in such a forum and helping to raise awareness about UX in the developer community by evolving key concepts and/or guides that will help them ‘get it’. Perhaps some of this could help within the D8 contrib cycle.

So as diverse as the opinions in this thread seem to be, I see a lot of very compatible perspectives. If we recognize that half the energy of this discussion is about UX Strategy and half is about the tactics required in the here-and-now to get D8 out the door in the best shape possible, we can probably find ways to collaborate more effectively in our various capacities.