Style Guides: wall or wiki?

[jonathan berger]

(I'm branching this off from the "[agile-usability] Valuing stories" thread.

> Personally much more of a stick stuff up on the wall type person than a wiki person in those situations - for all of the usual reasons.

I'd kept a styleguide on the wall, but it 1) tended to get out-of-date
pretty quickly, and 2) didn't provide access to the actual assets. At
a recent agile / UX meetup, someone gave a quick talk on the style
guide wiki they'd created for their team, and a lightbulb went off
over my head. Its less about "RTFM" and more about "I'll put that new
icon on the wiki so the next time you (or another dev) need it, its
there."

I'm in the process of migrating the styleguide from the wall /
illustrator doc to the wiki. I'd love to hear what other people are
doing to maintain consistency across the site and to make it easy for
devs to stay in-style.




_________________________
@jonathanpberger
http://www.marketpublique.com
http://www.jonathanpberger.com
718.930.2165
This email is:     [*] bloggable     [ ] ask first       [ ] private

[Adrian Howard]

On 8 Sep 2009, at 16:21, jonathan berger wrote:

> (I'm branching this off from the "[agile-usability] Valuing stories"  
> thread.
>
>> Personally much more of a stick stuff up on the wall type person  
>> than a wiki person in those situations - for all of the usual  
>> reasons.
>
> I'd kept a styleguide on the wall, but it 1) tended to get out-of-date
> pretty quickly,

Even better on the wall then - coz then folk see that there's a new  
one without having to go look on the wiki :-)

> and 2) didn't provide access to the actual assets. At
> a recent agile / UX meetup, someone gave a quick talk on the style
> guide wiki they'd created for their team, and a lightbulb went off
> over my head. Its less about "RTFM" and more about "I'll put that new
> icon on the wiki so the next time you (or another dev) need it, its
> there."

When it comes to assets like icons, style sheets, etc. I much prefer  
to keep those in whatever source control system the rest of the  
development team is using. That way nobody has to look "somewhere  
different" and copy it in. And you get all the normal advantages of  
source control.

> I'm in the process of migrating the styleguide from the wall /
> illustrator doc to the wiki. I'd love to hear what other people are
> doing to maintain consistency across the site and to make it easy for
> devs to stay in-style.

Assets under source control. Propaganda on the walls. Lots and lots  
and lots of talking :-)

The other thing is to try and get that consistency part of the code.  
Make sure that the concepts that are represented in the UI are also in  
the code. In the web world really solid semantic markup, good naming  
of CSS, appropriate uses of class/ID, etc.

Adrian
--
http://quietstars.com  -  twitter.com/adrianh  -  delicious.com/adrianh

[Adam Sroka-3]

On Tue, Sep 8, 2009 at 8:21 AM, jonathan
berger<jonathanpberger@...> wrote:

>
>
> (I'm branching this off from the "[agile-usability] Valuing stories" thread.
>
>> Personally much more of a stick stuff up on the wall type person than a
>> wiki person in those situations - for all of the usual reasons.
>
> I'd kept a styleguide on the wall, but it 1) tended to get out-of-date
> pretty quickly, and 2) didn't provide access to the actual assets. At
> a recent agile / UX meetup, someone gave a quick talk on the style
> guide wiki they'd created for their team, and a lightbulb went off
> over my head. Its less about "RTFM" and more about "I'll put that new
> icon on the wiki so the next time you (or another dev) need it, its
> there."
>

I'm all for putting the assets somewhere we can get to them. Kind of a
no-brainer, IMO. Personally, I like to put them right in the source
control, although I know some people object to this.

> I'm in the process of migrating the styleguide from the wall /
> illustrator doc to the wiki. I'd love to hear what other people are
> doing to maintain consistency across the site and to make it easy for
> devs to stay in-style.
>

On the other hand, I still don't believe in a "style guide."
Personally, I'd rather you just sit down and say, "We should do it
this way, because..." Or, at least, "You should not do it that way,
because..."

I will listen, and, for better or for worse, I will remember it the next time.

[Scott Preece-2]

>From: Adam Sroka <adam.sroka@...>

>>On the other hand, I still don't believe in a "style guide."
>>Personally, I'd rather you just sit down and say, "We should do it
>>this way, because..." Or, at least, "You should not do it that way,
>>because..."
>
>>I will listen, and, for better or for worse, I will remember it the next time.
---

The SGs I'm familiar with have much more detail than you or I or anyone else can remember without something to refer to...

regards,
scott

[Mike Dwyer-2]

What are the steps that go into you writing a style guide?  I ask because it
sounds like you hole up in a cave or office and carefully carve out your
ideas and then stand tall and strong against the Philistines.  And I am sure
that is a misperception, right?

 

Mike Dwyer
"Planning constantly peers into the future for indications as to where a
solution may emerge."

"A Plan is a complex situation, adapting to an emerging solution."

 

From: agile-usability@...
[mailto:agile-usability@...] On Behalf Of Adam Sroka
Sent: Tuesday, September 08, 2009 11:46 AM
To: agile-usability@...
Subject: Re: [agile-usability] Style Guides: wall or wiki?

 

 

On Tue, Sep 8, 2009 at 8:21 AM, jonathan
berger<jonathanpberger@... <mailto:jonathanpberger%40gmail.com> >
wrote:
>
>
> (I'm branching this off from the "[agile-usability] Valuing stories"
thread.

>
>> Personally much more of a stick stuff up on the wall type person than a
>> wiki person in those situations - for all of the usual reasons.
>
> I'd kept a styleguide on the wall, but it 1) tended to get out-of-date
> pretty quickly, and 2) didn't provide access to the actual assets. At
> a recent agile / UX meetup, someone gave a quick talk on the style
> guide wiki they'd created for their team, and a lightbulb went off
> over my head. Its less about "RTFM" and more about "I'll put that new
> icon on the wiki so the next time you (or another dev) need it, its
> there."
>

I'm all for putting the assets somewhere we can get to them. Kind of a
no-brainer, IMO. Personally, I like to put them right in the source
control, although I know some people object to this.

> I'm in the process of migrating the styleguide from the wall /
> illustrator doc to the wiki. I'd love to hear what other people are
> doing to maintain consistency across the site and to make it easy for
> devs to stay in-style.
>

On the other hand, I still don't believe in a "style guide."
Personally, I'd rather you just sit down and say, "We should do it
this way, because..." Or, at least, "You should not do it that way,
because..."

I will listen, and, for better or for worse, I will remember it the next
time.




 
 

[Adam Sroka-3]

On Tue, Sep 8, 2009 at 9:09 AM, Scott Preece<sepreece@...> wrote:

>
>
>>From: Adam Sroka <adam.sroka@...>
>
>>>On the other hand, I still don't believe in a "style guide."
>>>Personally, I'd rather you just sit down and say, "We should do it
>>>this way, because..." Or, at least, "You should not do it that way,
>>>because..."
>>
>>>I will listen, and, for better or for worse, I will remember it the next
>>> time.
> ---
>
> The SGs I'm familiar with have much more detail than you or I or anyone else
> can remember without something to refer to...
>

Sounds like a usability problem.

[George Dinwiddie]

jonathan berger wrote:
> I'm in the process of migrating the styleguide from the wall /
> illustrator doc to the wiki. I'd love to hear what other people are
> doing to maintain consistency across the site and to make it easy for
> devs to stay in-style.

Jonathan, I think that neither the wall or the wiki are "the right
place."  The style guide needs to be in the heads of the developers and
UX designers.  As it changes, everyone needs to internalize those
changes, rather than having to continuously refer to a document.

In order for this to happen, the style guide needs to be relatively
small, so it can be held in the head.  And it needs to be developed with
everyone's involvement, not handed down from "the experts."

William Wake's "Java coding standard on one page"
(http://xp123.com/xplor/xp0002f/codingstd.gif) is an analogous
situation.  If your style guide gets too detailed, it becomes a
hindrance rather than a help.

As to where you /document/ the style guide that's in everyone's head, I
don't have strong opinions on that.  I do believe that everyone involved
should be able to fundamentally recreate the current style guide on the
whiteboard at any time.  That's the test for me.

  - George

--
  ----------------------------------------------------------------------
   * George Dinwiddie *                      http://blog.gdinwiddie.com
   Software Development                    http://www.idiacomputing.com
   Consultant and Coach                    http://www.agilemaryland.org
  ----------------------------------------------------------------------

[JG-6]

Jonathan Berger said:

"At a recent agile / UX meetup, someone gave a quick talk on the style
guide wiki they'd created for their team, and a lightbulb went off
over my head. Its less about "RTFM" and more about "I'll put that new
icon on the wiki so the next time you (or another dev) need it, its
there."


Hey, that was me!

In our, albeit nascent, experience the style guide is critical to our success. By defining the basic building blocks of our interactions, we remove the need to design and re-design and, perhaps more importantly, re-DEFINE them each iteration.

It allows us to reduce our documentation and focus on the core UX issues for that iteration. It, in fact, enables us to create just the minimal amount of documentation because all of the "infrastructure" components are already defined, accessible globally and not, at the moment, up for debate. That does not mean we don't question them but, if they work for this iteration, they stay as defined.


Adam Sroka said:
"On the other hand, I still don't believe in a "style guide."
> >>Personally, I'd rather you just sit down and say, "We should do it
> >>this way, because..." Or, at least, "You should not do it that way,
> >>because..."
> >
> >>I will listen, and, for better or for worse, I will remember it the next time."

That's cool and if you were the only developer on my team we could have that discourse on a daily basis. But I lead a shared services UX team that spans multiple business lines and dozens of developers. A centralized, accessible and current style guide (in Wiki format, in our case) allows us to maintain and update these assets without having all of these individual conversations about infrastructure.

[Jeff]
====================
Jeff Gothelf
Director of UX
TheLadders.com



--- In agile-usability@..., Scott Preece <sepreece@...> wrote:

>
>
> >From: Adam Sroka <adam.sroka@...>
>
> >>On the other hand, I still don't believe in a "style guide."
> >>Personally, I'd rather you just sit down and say, "We should do it
> >>this way, because..." Or, at least, "You should not do it that way,
> >>because..."
> >
> >>I will listen, and, for better or for worse, I will remember it the next time.
> ---
>
> The SGs I'm familiar with have much more detail than you or I or anyone else can remember without something to refer to...
>
> regards,
> scott
>

[William Pietri]

Adam Sroka wrote:
> On the other hand, I still don't believe in a "style guide."
> Personally, I'd rather you just sit down and say, "We should do it
> this way, because..." Or, at least, "You should not do it that way,
> because..."

I don't think this is an either/or.

I have seen style guides used poorly, where designers use them as part
of an attempt to treat developers as robots programmed via paper.

But I've seen them used well where you have a lot of people working on
facets of one product, as with big web properties. There, though, I
suspect more of the value comes from driving consistency among
designers, rather than saving designer/developer labor.

They still worry me some, though, because of the potential for
expressive duplication. A lot of shops instead solve consistency
problems through keeping duplication to a minimum. E.g., they keep logos
consistent by having exactly one place to find them in the source code
repository, and keep text style consistent through disciplined use of
shared CSS.

William

[JG-6]

Writing a style guide consisted of the following steps for us:

1. define the scope of the style guide (i.e., what elements will be defined)

2. assign chunks of the style guide to different folks (typically UX) to define and publish

3. get buy-in on anything that may be considered "controversial"

4. publish and provide access company-wide

5. implement opportunistically


For us, total time to author and publish the style guide was less than one sprint!

Total time to implement opportunistically has been ~7 months.

[Jeff]
===============
Jeff Gothelf
Director of UX
TheLadders.com



--- In agile-usability@..., "Mike Dwyer" <mdwyer@...> wrote:

>
> What are the steps that go into you writing a style guide?  I ask because it
> sounds like you hole up in a cave or office and carefully carve out your
> ideas and then stand tall and strong against the Philistines.  And I am sure
> that is a misperception, right?
>
>  
>
> Mike Dwyer
> "Planning constantly peers into the future for indications as to where a
> solution may emerge."
>
> "A Plan is a complex situation, adapting to an emerging solution."
>
>  
>
> From: agile-usability@...
> [mailto:agile-usability@...] On Behalf Of Adam Sroka
> Sent: Tuesday, September 08, 2009 11:46 AM
> To: agile-usability@...
> Subject: Re: [agile-usability] Style Guides: wall or wiki?
>
>  
>
>  
>
> On Tue, Sep 8, 2009 at 8:21 AM, jonathan
> berger<jonathanpberger@... <mailto:jonathanpberger%40gmail.com> >
> wrote:
> >
> >
> > (I'm branching this off from the "[agile-usability] Valuing stories"
> thread.
> >
> >> Personally much more of a stick stuff up on the wall type person than a
> >> wiki person in those situations - for all of the usual reasons.
> >
> > I'd kept a styleguide on the wall, but it 1) tended to get out-of-date
> > pretty quickly, and 2) didn't provide access to the actual assets. At
> > a recent agile / UX meetup, someone gave a quick talk on the style
> > guide wiki they'd created for their team, and a lightbulb went off
> > over my head. Its less about "RTFM" and more about "I'll put that new
> > icon on the wiki so the next time you (or another dev) need it, its
> > there."
> >
>
> I'm all for putting the assets somewhere we can get to them. Kind of a
> no-brainer, IMO. Personally, I like to put them right in the source
> control, although I know some people object to this.
>
> > I'm in the process of migrating the styleguide from the wall /
> > illustrator doc to the wiki. I'd love to hear what other people are
> > doing to maintain consistency across the site and to make it easy for
> > devs to stay in-style.
> >
>
> On the other hand, I still don't believe in a "style guide."
> Personally, I'd rather you just sit down and say, "We should do it
> this way, because..." Or, at least, "You should not do it that way,
> because..."
>
> I will listen, and, for better or for worse, I will remember it the next
> time.
>

[Jeanne Hallock]

>> I'm in the process of migrating the styleguide from the wall /illustrator
doc to the wiki. I'd love to hear what other people are
doing to maintain consistency across the site and to make it easy for devs
to stay in-style.

Where you keep it really depends on your company's culture and where your
developers are more likely to go looking for it. I work in a large
multinational company which is extremely conservative and is not a software
or internet company (i.e. software isn't our business).  We are not allowed
to post anything on walls, not even our user stories for an iteration.

So we are forced to use websites and wikis for just about everything. Our
style guide which contains both styles and patterns is on a separate
internal web site. We actually had developers who found the site before it
was officially released and started using it.

Our wiki is heavily used, but is considered for work in process only.
Stories and tasks are kept on display boards which are sometimes hidden from
view in a cubicle corner or are other wise kept folded up. Our business
requirements are on a wiki under a story and this more often than not where
our developers are working from. (Yes, I know. I call it 'institutionalized'
agile.)

We have a standard css file, actually a java jar file, which is based off of
the style guide website. When a new jar is released, we just pop it in and
make any needed adjustments.  For any non-standard styles needed for
business reasons, either the developers or I create depending on my time or
their ability.

Thanks,
Jeanne Hallock
UX Designer and Developer

[Mike Dwyer-2]

Thanks

Another question, you mention that it was done within a sprint but that
different parts were assigned to folks

 

Was the scoping done prior to the sprint in the planning meeting or broken
into chunks and made into stories?

Why did you have to assign it out to team members?

Did you encourage collaboration? I ask because you talk about  getting
feedback?  Who were you looking for feedback from?

Was the Product Owner involved and how?

 

I get the feeling that you are trying to move to an agile frame but are
staying in a conventional process.  Is that the case?

 

Mike Dwyer
"Planning constantly peers into the future for indications as to where a
solution may emerge."

"A Plan is a complex situation, adapting to an emerging solution."

 

From: agile-usability@...
[mailto:agile-usability@...] On Behalf Of whyjg
Sent: Tuesday, September 08, 2009 12:54 PM
To: agile-usability@...
Subject: [agile-usability] Re: Style Guides: wall or wiki?

 

 

Writing a style guide consisted of the following steps for us:

1. define the scope of the style guide (i.e., what elements will be defined)

2. assign chunks of the style guide to different folks (typically UX) to
define and publish

3. get buy-in on anything that may be considered "controversial"

4. publish and provide access company-wide

5. implement opportunistically

For us, total time to author and publish the style guide was less than one
sprint!

Total time to implement opportunistically has been ~7 months.

[Jeff]
===============
Jeff Gothelf
Director of UX
TheLadders.com

--- In agile-usability@...
<mailto:agile-usability%40yahoogroups.com> , "Mike Dwyer" <mdwyer@...>
wrote:
>
> What are the steps that go into you writing a style guide? I ask because
it
> sounds like you hole up in a cave or office and carefully carve out your
> ideas and then stand tall and strong against the Philistines. And I am
sure

> that is a misperception, right?
>
>
>
> Mike Dwyer
> "Planning constantly peers into the future for indications as to where a
> solution may emerge."
>
> "A Plan is a complex situation, adapting to an emerging solution."
>
>
>
> From: agile-usability@...

<mailto:agile-usability%40yahoogroups.com>
> [mailto:agile-usability@...
<mailto:agile-usability%40yahoogroups.com> ] On Behalf Of Adam Sroka
> Sent: Tuesday, September 08, 2009 11:46 AM
> To: agile-usability@...
<mailto:agile-usability%40yahoogroups.com>

> Subject: Re: [agile-usability] Style Guides: wall or wiki?
>
>
>
>
>
> On Tue, Sep 8, 2009 at 8:21 AM, jonathan
> berger<jonathanpberger@... <mailto:jonathanpberger%40gmail.com> >
> wrote:
> >
> >
> > (I'm branching this off from the "[agile-usability] Valuing stories"
> thread.
> >
> >> Personally much more of a stick stuff up on the wall type person than a
> >> wiki person in those situations - for all of the usual reasons.
> >
> > I'd kept a styleguide on the wall, but it 1) tended to get out-of-date
> > pretty quickly, and 2) didn't provide access to the actual assets. At
> > a recent agile / UX meetup, someone gave a quick talk on the style
> > guide wiki they'd created for their team, and a lightbulb went off
> > over my head. Its less about "RTFM" and more about "I'll put that new
> > icon on the wiki so the next time you (or another dev) need it, its
> > there."
> >
>
> I'm all for putting the assets somewhere we can get to them. Kind of a
> no-brainer, IMO. Personally, I like to put them right in the source
> control, although I know some people object to this.
>
> > I'm in the process of migrating the styleguide from the wall /
> > illustrator doc to the wiki. I'd love to hear what other people are
> > doing to maintain consistency across the site and to make it easy for
> > devs to stay in-style.
> >
>
> On the other hand, I still don't believe in a "style guide."
> Personally, I'd rather you just sit down and say, "We should do it
> this way, because..." Or, at least, "You should not do it that way,
> because..."
>
> I will listen, and, for better or for worse, I will remember it the next
> time.
>

 
 

[JG-6]

The style guide creation process was executed outside of the Agile framework. It was owned wholly by the UX team and distributed among the members of the team where their expertise made sense.

Feedback/buy-in was sought to ensure all were on board as we moved to implement elements of the style guide.

This was all done in advance of the shift to Agile (so, yes, we were still in a conventional model) so that the team would at least have this critical element complete before the full switch over.

[Jeff]

--- In agile-usability@..., "Mike Dwyer" <mdwyer@...> wrote:

>
> Thanks
>
> Another question, you mention that it was done within a sprint but that
> different parts were assigned to folks
>
>  
>
> Was the scoping done prior to the sprint in the planning meeting or broken
> into chunks and made into stories?
>
> Why did you have to assign it out to team members?
>
> Did you encourage collaboration? I ask because you talk about  getting
> feedback?  Who were you looking for feedback from?
>
> Was the Product Owner involved and how?
>
>  
>
> I get the feeling that you are trying to move to an agile frame but are
> staying in a conventional process.  Is that the case?
>
>  
>
> Mike Dwyer
> "Planning constantly peers into the future for indications as to where a
> solution may emerge."
>
> "A Plan is a complex situation, adapting to an emerging solution."
>
>  
>
> From: agile-usability@...
> [mailto:agile-usability@...] On Behalf Of whyjg
> Sent: Tuesday, September 08, 2009 12:54 PM
> To: agile-usability@...
> Subject: [agile-usability] Re: Style Guides: wall or wiki?
>
>  
>
>  
>
> Writing a style guide consisted of the following steps for us:
>
> 1. define the scope of the style guide (i.e., what elements will be defined)
>
> 2. assign chunks of the style guide to different folks (typically UX) to
> define and publish
>
> 3. get buy-in on anything that may be considered "controversial"
>
> 4. publish and provide access company-wide
>
> 5. implement opportunistically
>
> For us, total time to author and publish the style guide was less than one
> sprint!
>
> Total time to implement opportunistically has been ~7 months.
>
> [Jeff]
> ===============
> Jeff Gothelf
> Director of UX
> TheLadders.com
>
> --- In agile-usability@...
> <mailto:agile-usability%40yahoogroups.com> , "Mike Dwyer" <mdwyer@>
> wrote:
> >
> > What are the steps that go into you writing a style guide? I ask because
> it
> > sounds like you hole up in a cave or office and carefully carve out your
> > ideas and then stand tall and strong against the Philistines. And I am
> sure
> > that is a misperception, right?
> >
> >
> >
> > Mike Dwyer
> > "Planning constantly peers into the future for indications as to where a
> > solution may emerge."
> >
> > "A Plan is a complex situation, adapting to an emerging solution."
> >
> >
> >
> > From: agile-usability@...
> <mailto:agile-usability%40yahoogroups.com>
> > [mailto:agile-usability@...
> <mailto:agile-usability%40yahoogroups.com> ] On Behalf Of Adam Sroka
> > Sent: Tuesday, September 08, 2009 11:46 AM
> > To: agile-usability@...
> <mailto:agile-usability%40yahoogroups.com>
> > Subject: Re: [agile-usability] Style Guides: wall or wiki?
> >
> >
> >
> >
> >
> > On Tue, Sep 8, 2009 at 8:21 AM, jonathan
> > berger<jonathanpberger@ <mailto:jonathanpberger%40gmail.com> >
> > wrote:
> > >
> > >
> > > (I'm branching this off from the "[agile-usability] Valuing stories"
> > thread.
> > >
> > >> Personally much more of a stick stuff up on the wall type person than a
> > >> wiki person in those situations - for all of the usual reasons.
> > >
> > > I'd kept a styleguide on the wall, but it 1) tended to get out-of-date
> > > pretty quickly, and 2) didn't provide access to the actual assets. At
> > > a recent agile / UX meetup, someone gave a quick talk on the style
> > > guide wiki they'd created for their team, and a lightbulb went off
> > > over my head. Its less about "RTFM" and more about "I'll put that new
> > > icon on the wiki so the next time you (or another dev) need it, its
> > > there."
> > >
> >
> > I'm all for putting the assets somewhere we can get to them. Kind of a
> > no-brainer, IMO. Personally, I like to put them right in the source
> > control, although I know some people object to this.
> >
> > > I'm in the process of migrating the styleguide from the wall /
> > > illustrator doc to the wiki. I'd love to hear what other people are
> > > doing to maintain consistency across the site and to make it easy for
> > > devs to stay in-style.
> > >
> >
> > On the other hand, I still don't believe in a "style guide."
> > Personally, I'd rather you just sit down and say, "We should do it
> > this way, because..." Or, at least, "You should not do it that way,
> > because..."
> >
> > I will listen, and, for better or for worse, I will remember it the next
> > time.
> >
>

[Scott Preece-2]

In our case, the SG was written by a UX team that included people from several technical disciplines. It was developed iteratively based on user testing and customer feedback. There was regular review with people from the development teams and the product teams (that is, those responsible for selling the product to customers).

regards,
scott

>
>From: Mike Dwyer <mdwyer@...>
>To: agile-usability@...
>Sent: Tuesday, September 8, 2009 11:23:58 AM
>Subject: RE: [agile-usability] Style Guides: wall or wiki?
>
>  
>>
>
>
>
>
>>
>What are the steps that go into you writing a style guide?  I
>ask because it sounds like you hole up in a cave or office and carefully carve
>out your ideas and then stand tall and strong against the Philistines.  And I
>am sure that is a misperception, right?
>
>>
>Mike Dwyer
>"Planning
>constantly peers into the future for indications as to where a solution may
>emerge."
>"A Plan is a complex
>situation, adapting to an emerging solution."
>
>>
>>
>From:>agile-usability@ yahoogroups. com [mailto:agile- usability@ yahoogroups. com] On
>Behalf Of Adam Sroka
>Sent: Tuesday, September 08, 2009 11:46 AM
>To: agile-usability@ yahoogroups. com
>Subject: Re: [agile-usability] Style Guides: wall or wiki?
>
>  
>>
>>
>>
>On Tue, Sep 8, 2009 at 8:21 AM, jonathan
>>berger<jonathanpberger@ gmail.com>
>wrote:
>>>
>>>
>>> (I'm branching this off from the "[agile-usability] Valuing
>stories" thread.
>>>
>>>> Personally much more of a stick stuff up on the wall type person than
>a
>>>> wiki person in those situations - for all of the usual reasons.
>>>
>>> I'd kept a styleguide on the wall, but it 1) tended to get out-of-date
>>> pretty quickly, and 2) didn't provide access to the actual assets. At
>>> a recent agile / UX meetup, someone gave a quick talk on the style
>>> guide wiki they'd created for their team, and a lightbulb went off
>>> over my head. Its less about "RTFM" and more about "I'll
>put that new
>>> icon on the wiki so the next time you (or another dev) need it, its
>>> there."
>>>
>
>>I'm all for putting the assets somewhere we can get to them. Kind of a
>>no-brainer, IMO. Personally, I like to put them right in the source
>>control, although I know some people object to this.
>
>>> I'm in the process of migrating the styleguide from the wall /
>>> illustrator doc to the wiki. I'd love to hear what other people are
>>> doing to maintain consistency across the site and to make it easy for
>>> devs to stay in-style.
>>>
>
>>On the other hand, I still don't believe in a "style guide."
>>Personally, I'd rather you just sit down and say, "We should do it
>>this way, because..." Or, at least, "You should not do it that way,
>>because..."
>
>>I will listen, and, for better or for worse, I will remember it the next time.
>>
> > >  

[Mike Dwyer-2]

With all this iterative feedback, did you freeze the Style Guide (SG?) then
implement or did you continue the iteration on the SG?  How did rework go?

 

Mike Dwyer
"Planning constantly peers into the future for indications as to where a
solution may emerge."

"A Plan is a complex situation, adapting to an emerging solution."

 

From: agile-usability@...
[mailto:agile-usability@...] On Behalf Of Scott Preece
Sent: Tuesday, September 08, 2009 2:13 PM
To: agile-usability@...
Subject: Re: [agile-usability] Style Guides: wall or wiki?

 

 

In our case, the SG was written by a UX team that included people from
several technical disciplines. It was developed iteratively based on user
testing and customer feedback. There was regular review with people from the
development teams and the product teams (that is, those responsible for
selling the product to customers).

regards,
scott



 

From: Mike Dwyer <mdwyer@...>
To: agile-usability@...
Sent: Tuesday, September 8, 2009 11:23:58 AM
Subject: RE: [agile-usability] Style Guides: wall or wiki?

 

What are the steps that go into you writing a style guide?  I ask because it
sounds like you hole up in a cave or office and carefully carve out your
ideas and then stand tall and strong against the Philistines.  And I am sure
that is a misperception, right?

 

Mike Dwyer
"Planning constantly peers into the future for indications as to where a
solution may emerge."

"A Plan is a complex situation, adapting to an emerging solution."

 

From: agile-usability@ yahoogroups. com [mailto:agile- usability@
yahoogroups. com] On Behalf Of Adam Sroka
Sent: Tuesday, September 08, 2009 11:46 AM
To: agile-usability@ yahoogroups. com
Subject: Re: [agile-usability] Style Guides: wall or wiki?

 

 

On Tue, Sep 8, 2009 at 8:21 AM, jonathan
berger<jonathanpberger@ <mailto:jonathanpberger%40gmail.com>  gmail.com>
wrote:
>
>
> (I'm branching this off from the "[agile-usability] Valuing stories"
thread.

>
>> Personally much more of a stick stuff up on the wall type person than a
>> wiki person in those situations - for all of the usual reasons.
>
> I'd kept a styleguide on the wall, but it 1) tended to get out-of-date
> pretty quickly, and 2) didn't provide access to the actual assets. At
> a recent agile / UX meetup, someone gave a quick talk on the style
> guide wiki they'd created for their team, and a lightbulb went off
> over my head. Its less about "RTFM" and more about "I'll put that new
> icon on the wiki so the next time you (or another dev) need it, its
> there."
>

I'm all for putting the assets somewhere we can get to them. Kind of a
no-brainer, IMO. Personally, I like to put them right in the source
control, although I know some people object to this.

> I'm in the process of migrating the styleguide from the wall /
> illustrator doc to the wiki. I'd love to hear what other people are
> doing to maintain consistency across the site and to make it easy for
> devs to stay in-style.
>

On the other hand, I still don't believe in a "style guide."
Personally, I'd rather you just sit down and say, "We should do it
this way, because..." Or, at least, "You should not do it that way,
because..."

I will listen, and, for better or for worse, I will remember it the next
time.




 
 

[Scott Preece-2]

This is well described!

I would just add (or emphasize) that the key goal of having an effective Style Guide is to avoid having to pre-design every application in detail. That is, the SG defines the set of building blocks and if it has been taught well to the developers, they then know how to structure the UX for a given function so that it is consistent with the rest of the product.

Ideally, this gets realized in a toolkit that the developers can use to easily implement the specifics without having to think about them very much, whether that implementation is a set of standard CSS styles, a collection of standard widgets, or (in our case) a UIMS.

regards,
scott

>
>From: whyjg <whyjg@...>
>To: agile-usability@...
>Sent: Tuesday, September 8, 2009 11:43:16 AM
>Subject: [agile-usability] Re: Style Guides: wall or wiki?
>
>  
>Jonathan Berger said:
>
>>"At a recent agile / UX meetup, someone gave a quick talk on the style
>>guide wiki they'd created for their team, and a lightbulb went off
>>over my head. Its less about "RTFM" and more about "I'll put that new
>>icon on the wiki so the next time you (or another dev) need it, its
>>there."
>
>>Hey, that was me!
>
>>In our, albeit nascent, experience the style guide is critical to our success. By defining the basic building blocks of our interactions, we remove the need to design and re-design and, perhaps more importantly, re-DEFINE them each iteration.
>
>>It allows us to reduce our documentation and focus on the core UX issues for that iteration. It, in fact, enables us to create just the minimal amount of documentation because all of the "infrastructure" components are already defined, accessible globally and not, at the moment, up for debate. That does not mean we don't question them but, if they work for this iteration, they stay as defined.
>
>>Adam Sroka said:
>>"On the other hand, I still don't believe in a "style guide."
>>> >>Personally, I'd rather you just sit down and say, "We should do it
>>> >>this way, because..." Or, at least, "You should not do it that way,
>>> >>because... "
>>> >
>>> >>I will listen, and, for better or for worse, I will remember it the next time."
>
>>That's cool and if you were the only developer on my team we could have that discourse on a daily basis. But I lead a shared services UX team that spans multiple business lines and dozens of developers. A centralized, accessible and current style guide (in Wiki format, in our case) allows us to maintain and update these assets without having all of these individual conversations about infrastructure.
>
>>[Jeff]
>>============ ========
>>Jeff Gothelf
>>Director of UX
>TheLadders.com
>
>>--- In agile-usability@ yahoogroups. com, Scott Preece <sepreece@.. .> wrote:
>>>
>>>
>>> >From: Adam Sroka <adam.sroka@ ...>
>>>
>>> >>On the other hand, I still don't believe in a "style guide."
>>> >>Personally, I'd rather you just sit down and say, "We should do it
>>> >>this way, because..." Or, at least, "You should not do it that way,
>>> >>because... "
>>> >
>>> >>I will listen, and, for better or for worse, I will remember it the next time.
>>> ---
>>>
>>> The SGs I'm familiar with have much more detail than you or I or anyone else can remember without something to refer to...
>>>
>>> regards,
>>> scott
>>>
>
>
> > >  

[Mike Dwyer-2]

Thxs.

 

Mike Dwyer
Principal Agile Consultant

BigVisible Solutions
url:    http://www.bigvisible.com <http://www.bigvisible.com/>

cell:   [phone]

email: mdwyer@... <mailto:asingh@...>

 

 

From: agile-usability@...
[mailto:agile-usability@...] On Behalf Of whyjg
Sent: Tuesday, September 08, 2009 2:03 PM
To: agile-usability@...
Subject: [agile-usability] Re: Style Guides: wall or wiki?

 

 

The style guide creation process was executed outside of the Agile
framework. It was owned wholly by the UX team and distributed among the
members of the team where their expertise made sense.

Feedback/buy-in was sought to ensure all were on board as we moved to
implement elements of the style guide.

This was all done in advance of the shift to Agile (so, yes, we were still
in a conventional model) so that the team would at least have this critical
element complete before the full switch over.

[Jeff]

--- In agile-usability@...
<mailto:agile-usability%40yahoogroups.com> , "Mike Dwyer" <mdwyer@...>
wrote:

>
> Thanks
>
> Another question, you mention that it was done within a sprint but that
> different parts were assigned to folks
>
>
>
> Was the scoping done prior to the sprint in the planning meeting or broken
> into chunks and made into stories?
>
> Why did you have to assign it out to team members?
>
> Did you encourage collaboration? I ask because you talk about getting
> feedback? Who were you looking for feedback from?
>
> Was the Product Owner involved and how?
>
>
>
> I get the feeling that you are trying to move to an agile frame but are
> staying in a conventional process. Is that the case?
>
>
>
> Mike Dwyer
> "Planning constantly peers into the future for indications as to where a
> solution may emerge."
>
> "A Plan is a complex situation, adapting to an emerging solution."
>
>
>
> From: agile-usability@...

<mailto:agile-usability%40yahoogroups.com>
> [mailto:agile-usability@...
<mailto:agile-usability%40yahoogroups.com> ] On Behalf Of whyjg
> Sent: Tuesday, September 08, 2009 12:54 PM
> To: agile-usability@...
<mailto:agile-usability%40yahoogroups.com>
> Subject: [agile-usability] Re: Style Guides: wall or wiki?
>
>
>
>
>
> Writing a style guide consisted of the following steps for us:
>
> 1. define the scope of the style guide (i.e., what elements will be
defined)

>
> 2. assign chunks of the style guide to different folks (typically UX) to
> define and publish
>
> 3. get buy-in on anything that may be considered "controversial"
>
> 4. publish and provide access company-wide
>
> 5. implement opportunistically
>
> For us, total time to author and publish the style guide was less than one
> sprint!
>
> Total time to implement opportunistically has been ~7 months.
>
> [Jeff]
> ===============
> Jeff Gothelf
> Director of UX
> TheLadders.com
>
> --- In agile-usability@...

<mailto:agile-usability%40yahoogroups.com>

> <mailto:agile-usability%40yahoogroups.com> , "Mike Dwyer" <mdwyer@>
> wrote:
> >
> > What are the steps that go into you writing a style guide? I ask because
> it
> > sounds like you hole up in a cave or office and carefully carve out your
> > ideas and then stand tall and strong against the Philistines. And I am
> sure
> > that is a misperception, right?
> >
> >
> >
> > Mike Dwyer
> > "Planning constantly peers into the future for indications as to where a
> > solution may emerge."
> >
> > "A Plan is a complex situation, adapting to an emerging solution."
> >
> >
> >
> > From: agile-usability@...

<mailto:agile-usability%40yahoogroups.com>
> <mailto:agile-usability%40yahoogroups.com>
> > [mailto:agile-usability@...
<mailto:agile-usability%40yahoogroups.com>
> <mailto:agile-usability%40yahoogroups.com> ] On Behalf Of Adam Sroka
> > Sent: Tuesday, September 08, 2009 11:46 AM
> > To: agile-usability@...
<mailto:agile-usability%40yahoogroups.com>

> <mailto:agile-usability%40yahoogroups.com>
> > Subject: Re: [agile-usability] Style Guides: wall or wiki?
> >
> >
> >
> >
> >
> > On Tue, Sep 8, 2009 at 8:21 AM, jonathan
> > berger<jonathanpberger@ <mailto:jonathanpberger%40gmail.com> >
> > wrote:
> > >
> > >
> > > (I'm branching this off from the "[agile-usability] Valuing stories"
> > thread.
> > >
> > >> Personally much more of a stick stuff up on the wall type person than

a

> > >> wiki person in those situations - for all of the usual reasons.
> > >
> > > I'd kept a styleguide on the wall, but it 1) tended to get out-of-date
> > > pretty quickly, and 2) didn't provide access to the actual assets. At
> > > a recent agile / UX meetup, someone gave a quick talk on the style
> > > guide wiki they'd created for their team, and a lightbulb went off
> > > over my head. Its less about "RTFM" and more about "I'll put that new
> > > icon on the wiki so the next time you (or another dev) need it, its
> > > there."
> > >
> >
> > I'm all for putting the assets somewhere we can get to them. Kind of a
> > no-brainer, IMO. Personally, I like to put them right in the source
> > control, although I know some people object to this.
> >
> > > I'm in the process of migrating the styleguide from the wall /
> > > illustrator doc to the wiki. I'd love to hear what other people are
> > > doing to maintain consistency across the site and to make it easy for
> > > devs to stay in-style.
> > >
> >
> > On the other hand, I still don't believe in a "style guide."
> > Personally, I'd rather you just sit down and say, "We should do it
> > this way, because..." Or, at least, "You should not do it that way,
> > because..."
> >
> > I will listen, and, for better or for worse, I will remember it the next
> > time.
> >
>

 
 

[jonathan berger]

> the key goal of having an effective Style Guide is to avoid having to pre-design every application in detail...the SG defines the set of building blocks

+1

Also:

- I'm using the github wiki as the basis for the SG, so that images
are linked to the actual binary under source control. Yes, I had to
add a  "mockups" folder to source control. So far that's been fine,
although it may not scale. We'll see...

- "Wall" and "wiki" aren't mutually exclusive; sorry if the title of
this thread is a little misleading. I'm more interested in small
tricks and hacks people are using. The genesis of our current SG was a
hand-scrawled sign posted on the wall by the devs, for the devs,
saying "Design pattern: keep the 'save' button on the same side. Right
or left?" When building, a lot of quick choices are made. If canonical
patterns are in eyeshot, things are done correctly the first time and
it saves a lot of effort on non-rejectable elements—I'm not going to
reject a feature because a button is used instead of a link—that'll
accumulate into design-debt.

On Tue, Sep 8, 2009 at 2:19 PM, Mike Dwyer<mdwyer@...> wrote:

>
>
> With all this iterative feedback, did you freeze the Style Guide (SG?) then
> implement or did you continue the iteration on the SG?  How did rework go?
>
>
>
> Mike Dwyer
> "Planning constantly peers into the future for indications as to where a
> solution may emerge."
>
> "A Plan is a complex situation, adapting to an emerging solution."
>
>
>
> From: agile-usability@...
> [mailto:agile-usability@...] On Behalf Of Scott Preece
> Sent: Tuesday, September 08, 2009 2:13 PM
>
> To: agile-usability@...
> Subject: Re: [agile-usability] Style Guides: wall or wiki?
>
>
>
>
>
> In our case, the SG was written by a UX team that included people from
> several technical disciplines. It was developed iteratively based on user
> testing and customer feedback. There was regular review with people from the
> development teams and the product teams (that is, those responsible for
> selling the product to customers).
>
> regards,
> scott
>
>
>
> From: Mike Dwyer <mdwyer@...>
> To: agile-usability@...
> Sent: Tuesday, September 8, 2009 11:23:58 AM
> Subject: RE: [agile-usability] Style Guides: wall or wiki?
>
>
>
> What are the steps that go into you writing a style guide?  I ask because it
> sounds like you hole up in a cave or office and carefully carve out your
> ideas and then stand tall and strong against the Philistines.  And I am sure
> that is a misperception, right?
>
>
>
> Mike Dwyer
> "Planning constantly peers into the future for indications as to where a
> solution may emerge."
>
> "A Plan is a complex situation, adapting to an emerging solution."
>
>
>
> From: agile-usability@ yahoogroups. com [mailto:agile- usability@
> yahoogroups. com] On Behalf Of Adam Sroka
> Sent: Tuesday, September 08, 2009 11:46 AM
> To: agile-usability@ yahoogroups. com
> Subject: Re: [agile-usability] Style Guides: wall or wiki?
>
>
>
>
>
> On Tue, Sep 8, 2009 at 8:21 AM, jonathan
> berger<jonathanpberger@ gmail.com> wrote:
>>
>>
>> (I'm branching this off from the "[agile-usability] Valuing stories"
>> thread.
>>
>>> Personally much more of a stick stuff up on the wall type person than a
>>> wiki person in those situations - for all of the usual reasons.
>>
>> I'd kept a styleguide on the wall, but it 1) tended to get out-of-date
>> pretty quickly, and 2) didn't provide access to the actual assets. At
>> a recent agile / UX meetup, someone gave a quick talk on the style
>> guide wiki they'd created for their team, and a lightbulb went off
>> over my head. Its less about "RTFM" and more about "I'll put that new
>> icon on the wiki so the next time you (or another dev) need it, its
>> there."
>>
>
> I'm all for putting the assets somewhere we can get to them. Kind of a
> no-brainer, IMO. Personally, I like to put them right in the source
> control, although I know some people object to this.
>
>> I'm in the process of migrating the styleguide from the wall /
>> illustrator doc to the wiki. I'd love to hear what other people are
>> doing to maintain consistency across the site and to make it easy for
>> devs to stay in-style.
>>
>
> On the other hand, I still don't believe in a "style guide."
> Personally, I'd rather you just sit down and say, "We should do it
> this way, because..." Or, at least, "You should not do it that way,
> because..."
>
> I will listen, and, for better or for worse, I will remember it the next
> time.
>
>

--
_________________________
@jonathanpberger
http://www.marketpublique.com
http://www.jonathanpberger.com
718.930.2165
This email is:     [*] bloggable     [ ] ask first       [ ] private


------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/agile-usability/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/agile-usability/join
    (Yahoo! ID required)

<*> To change settings via email:
    mailto:agile-usability-digest@...
    mailto:agile-usability-fullfeatured@...

<*> To unsubscribe from this group, send an email to:
    agile-usability-unsubscribe@...

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/

[Ron Jeffries-3]

Hello, Scott.  On Tuesday, September 8, 2009, at 2:20:56 PM, you
wrote:

> I would just add (or emphasize) that the key goal of having an
> effective Style Guide is to avoid having to pre-design every
> application in detail. That is, the SG defines the set of building
> blocks and if it has been taught well to the developers, they then
> know how to structure the UX for a given function so that it is
> consistent with the rest of the product.

> Ideally, this gets realized in a toolkit that the developers can
> use to easily implement the specifics without having to think
> about them very much, whether that implementation is a set of
> standard CSS styles, a collection of standard widgets, or (in our case) a UIMS.

I like the notion of having standard software items to use that
implement the style guide.

Where that isn't possible a running program with the instructions:
"Make yours like this" would beat out a lot of text.

Ron Jeffries
www.XProgramming.com
www.xprogramming.com/blog
Will Turner: This is either madness or brilliance.
Captain Jack Sparrow: It's remarkable how often those two traits coincide.

[Scott Preece-2]

Well, nothing about software is ever frozen until it's shipped (and maybe not even then, these days).

We tried to keep a particular product working against a particular version of the SG, and we tried to make only additive changes (not reworking the existing elements, but adding new ones for new scenarios as necessary). We monitored Customer Service to find out what didn't work and revised things as necessary. To the extent that we were able to encapsulate the UX in the UIMS, we could then update the UIMS and the places where things used specific UIMS capabilities that changed, but a lot of UX bled out of the UIMS (was implemented in app code rather than in the UIMS), largely as a result of organizational issues, and sometimes changes were hard to make.

New product lines had their own SGs, based on the predecessors (to preserve the brand), but taking advantage of different hardware capabilities (the very first version of the UX was for a 1.5 line, 7-segment display; the last one I saw covered QVGA color displays). There were sometimes just overlays on the base SG. (B/T/W - This was all pre-Wiki, paper documents).

scott

>
>From: Mike Dwyer <mdwyer@...>
>To: agile-usability@...
>Sent: Tuesday, September 8, 2009 1:19:40 PM
>Subject: RE: [agile-usability] Style Guides: wall or wiki?
>
>  
>>
>
>
>
>
>>
>With all this iterative feedback, did you freeze the Style Guide
>(SG?) then implement or did you continue the iteration on the SG?  How did
>rework go?
>
>>
>Mike Dwyer
>"Planning
>constantly peers into the future for indications as to where a solution may
>emerge."
>"A Plan is a complex
>situation, adapting to an emerging solution."
>
>>
>>
>From:>agile-usability@ yahoogroups. com [mailto:agile- usability@ yahoogroups. com] On
>Behalf Of Scott Preece
>Sent: Tuesday, September 08, 2009 2:13 PM
>To: agile-usability@ yahoogroups. com
>Subject: Re: [agile-usability] Style Guides: wall or wiki?
>
>  
>>
>>
>>
>>
>>
>In our case, the SG was written
>by a UX team that included people from several technical disciplines. It was
>developed iteratively based on user testing and customer feedback. There was
>regular review with people from the development teams and the product teams
>(that is, those responsible for selling the product to customers).
>
>>regards,
>>scott
>
>
>>>
>>>>
>>
>>>>
>>From:Mike Dwyer <mdwyer@bigvisible. com>
>>To: agile-usability@ yahoogroups. com
>>Sent: Tuesday, September 8, 2009 11:23:58 AM
>>Subject: RE: [agile-usability] Style Guides: wall or wiki?
>>
>>>>  
>>>>
>>>>
>>What are the steps that go into you
>>writing a style guide?  I ask because it sounds like you hole up in a cave
>>or office and carefully carve out your ideas and then stand tall and strong
>>against the Philistines.  And I am sure that is a misperception, right?
>>
>>>>
>>Mike Dwyer
>>"Planning constantly
>>peers into the future for indications as to where a solution may emerge."
>>"A Plan is a complex situation,
>>adapting to an emerging solution."
>>
>>>>
>>>>
>>From:>>agile-usability@ yahoogroups. com [mailto:agile- usability@ yahoogroups. com] On
>>Behalf Of Adam Sroka
>>Sent: Tuesday, September 08, 2009 11:46 AM
>>To: agile-usability@ yahoogroups. com
>>Subject: Re: [agile-usability] Style Guides: wall or wiki?
>>
>>
>>
>>>>
>>>>
>>>>
>>On Tue, Sep 8, 2009 at 8:21 AM, jonathan
>>>>berger<jonathanpberger@
>>gmail.com> wrote:
>>>>>
>>>>>
>>>>> (I'm branching this off from the "[agile-usability] Valuing
>>stories" thread.
>>>>>
>>>>>> Personally much more of a stick stuff up on the wall type person than
>>a
>>>>>> wiki person in those situations - for all of the usual reasons.
>>>>>
>>>>> I'd kept a styleguide on the wall, but it 1) tended to get out-of-date
>>>>> pretty quickly, and 2) didn't provide access to the actual assets. At
>>>>> a recent agile / UX meetup, someone gave a quick talk on the style
>>>>> guide wiki they'd created for their team, and a lightbulb went off
>>>>> over my head. Its less about "RTFM" and more about "I'll
>>put that new
>>>>> icon on the wiki so the next time you (or another dev) need it, its
>>>>> there."
>>>>>
>>
>>>>I'm all for putting the assets somewhere we can get to them. Kind of a
>>>>no-brainer, IMO. Personally, I like to put them right in the source
>>>>control, although I know some people object to this.
>>
>>>>> I'm in the process of migrating the styleguide from the wall /
>>>>> illustrator doc to the wiki. I'd love to hear what other people are
>>>>> doing to maintain consistency across the site and to make it easy for
>>>>> devs to stay in-style.
>>>>>
>>
>>>>On the other hand, I still don't believe in a "style guide."
>>>>Personally, I'd rather you just sit down and say, "We should do it
>>>>this way, because..." Or, at least, "You should not do it that way,
>>>>because..."
>>
>>>>I will listen, and, for better or for worse, I will remember it the next time.
>>
> > >