Library Integration and Standards

[Loren]

Hey everyone,

It looks like this movement is gaining momentum and there is continued
interest in Axure libraries. We're up to five by my last count, each
containing a relatively unique set of interesting widgets.

The aim of AXLIB, from my understanding, is to integrate all this into
a single useful place. Having put one of these libraries out myself,
I've been trying to determine how and when to integrate my own, and I
finally realized that my main hangup is a lack of standards. If we
just plopped my masters into the AXLIB currently, people using the
library would have some very inconsistent prototypes, using widgets
with various fonts, colors, level of fidelity, etc.

IMO we need to set some ground rules for the library, so that it can
be coherent and as useful as possible. These standards can at least
provide a guideline for widget developers:

- Width of widgets (assumed page width, perhaps)
- General look and feel, perhaps a simple color palette
- Level of fidelity
- Level of interactivity
- Use and documentation of Variables
- Use and documentation of Raised Events
- Fonts and font sizes

Agree? Disagree? Are there other areas that need standardization?

[Luke Perman]

I completely agree.

Hence the style / size etc. of the patterns in the library we have
just released. They all conform to the excellent UserFocus 960 grids,
and follow (to my mind) best practice for wireframe components - in
terms of an absence of colour, blue underlined links etc.

In the back of my mind I had always thought that I would need to edit
each new submission to the library so that it fit the style and
standard already presented.

I think you're right in that there should be a rudimentary set of
guidelines also.

The main criteria here is that everything is usable - in terms of
masters that can be dropped into wireframes time again, with little or
no editing, rather than simply being demonstrations of how to do things.

But in answer to your main question, yes, the goal here is a
standardised set of widgets, and your list of criteria is pretty near
the mark. I had already wondered how it's best to document use of
variables etc.

Admittedly I will be making some updates to a few masters in the
library, as I'm sure all authors will, as I try to refine and improve
certain behaviours.

Luke

[Fred Beecher]

On 11/11/08, Luke Perman <luke....@evoke-media.com> wrote:

In the back of my mind I had always thought that I would need to edit
each new submission to the library so that it fit the style and
standard already presented.

 

That makes sense to me too. This is a community effort, but in order for the library to remain usable it needs to be consistent. 

I think you're right in that there should be a rudimentary set of
guidelines also.

 

Agreed. Perhaps we need a master .RP file that has all the widget & text styles defined, and possibly some helpful "starter masters" like grids, etc. that help pattern builders conform to the standards from the beginning. This will reduce the amount of work the Librarians (heh) will have to do to integrate new patterns.

 

Come to think of it, maybe we should also consider a quarterly release schedule so that the library isn't being updated *constantly*.  

The main criteria here is that everything is usable - in terms of
masters that can be dropped into wireframes time again, with little or
no editing, rather than simply being demonstrations of how to do things.

 

I think we need to have documentation standards too. For example, I'd love to see the patterns described not only on the example pages but within the Page Notes section of the masters themselves. That way, when library users import the masters they still have some understanding of how they're set up and how they're used.

 

If we choose to do this, we may want to standardize what is *in* that documentation. Here are my suggestions: What it does (on the Web page), how it works, and example uses. We'd also want to document the variables used and events raised, possibly with descriptions (unless that's been covered in "how it works")

 

One very tactical recommendation: We should use a standard variable name for the variable we need to use to fake animation. "I call this variable AlwaysTrue."

 

Are there any other variables that get used for consistent purposes? (Anyone who says OnLoadVariable will get a smack in the head. ; )  

 

Here's one thing I don't get, though... what to do with specialized libraries like Ari's OS X library? Should those live on separately? I'm inclined to think so. But for ease of use, I think we should let the authors of these sorts of libraries distribute them *alongside* the standard library.

 

Thoughts?

F.

 

------------------------------------------------------------------------------------------
Fred Beecher
Sr. User Experience Consultant
Evantage Consulting
O: 612.230.3838 // M: 612.810.6745
IM: fbee...@gmail.com (google/msn) // fredevc (aim/yahoo)
T: http://twitter.com/fred_beecher

[Iain Lowe]

This is a great discussion.

On Tue, Nov 11, 2008 at 9:14 AM, Fred Beecher <fbee...@gmail.com> wrote:

I think we need to have documentation standards too. For example, I'd love to see the patterns described not only on the example pages but within the Page Notes section of the masters themselves. That way, when library users import the masters they still have some understanding of how they're set up and how they're used.

I am in total and complete agreement with this.
 

If we choose to do this, we may want to standardize what is *in* that documentation. Here are my suggestions: What it does (on the Web page), how it works, and example uses. We'd also want to document the variables used and events raised, possibly with descriptions (unless that's been covered in "how it works")

 

One very tactical recommendation: We should use a standard variable name for the variable we need to use to fake animation. "I call this variable AlwaysTrue."

 

Are there any other variables that get used for consistent purposes? (Anyone who says OnLoadVariable will get a smack in the head. ; )  

I create a lot of masters that depend on logged-in logged-out state. I use an isLoggedIn variable for this purpose. There are probably a set of booleans that we could set some standards around?
 

Here's one thing I don't get, though... what to do with specialized libraries like Ari's OS X library? Should those live on separately? I'm inclined to think so. But for ease of use, I think we should let the authors of these sorts of libraries distribute them *alongside* the standard library.

That's a tough one. I can see the core library set eventually getting chunked out into separate rp files for manageability over the long haul, so I think that having multiple specialized libraries will likely end up happening. For example, libraries for mobile prototyping would make sense living in their own silo, as would libraries for OS specific prototypes like Ari's.
 

[Ian Fenn]

Hi Fred,

On 11/11/2008 14:14, "Fred Beecher" <fbee...@gmail.com> wrote:
> Agreed. Perhaps we need a master .RP file that has all the widget & text
> styles defined, and possibly some helpful "starter masters" like grids, etc.
> that help pattern builders conform to the standards from the beginning. This
> will reduce the amount of work the Librarians (heh) will have to do to
> integrate new patterns.

I'm looking at this currently, along with further patterns to add. :-)

> Come to think of it, maybe we should also consider a quarterly release
> schedule so that the library isn't being updated *constantly*.

I think that would work in the long run, however during these initial
stages, Luke and I are aiming at a monthly release subject to our work and
family commitments.

> I think we need to have documentation standards too. For example, I'd love to
> see the patterns described not only on the example pages but within the Page
> Notes section of the masters themselves. That way, when library users import
> the masters they still have some understanding of how they're set up and how
> they're used.

We'll certainly look at that. We're also sorting out a permanent location
for the built prototype as a demo.

> If we choose to do this, we may want to standardize what is *in* that
> documentation. Here are my suggestions: What it does (on the Web page), how it
> works, and example uses. We'd also want to document the variables used and
> events raised, possibly with descriptions (unless that's been covered in "how
> it works")

Good idea.

> One very tactical recommendation: We should use a standard variable name for
> the variable we need to use to fake animation. "I call this variable
> AlwaysTrue."
>
> Are there any other variables that get used for consistent purposes? (Anyone
> who says OnLoadVariable will get a smack in the head. ; )

:-)

> Here's one thing I don't get, though... what to do with specialized libraries
> like Ari's OS X library? Should those live on separately? I'm inclined to
> think so. But for ease of use, I think we should let the authors of these
> sorts of libraries distribute them *alongside* the standard library.

I agree.

All the best,

--
Ian Fenn
Certified Usability Analyst
Chopstix Media Limited
http://www.chopstixmedia.com/

[Ian Fenn]

Hi Iain,

On 11/11/2008 18:39, "Iain Lowe" <ilow...@gmail.com> wrote:
> I can see the core library set eventually getting chunked
> out into separate rp files for manageability over the long haul, so I think
> that having multiple specialized libraries will likely end up happening. For
> example, libraries for mobile prototyping would make sense living in their own
> silo, as would libraries for OS specific prototypes like Ari's.

I agree, though I'd personally like to see AXLIB as a single .rp file for as
long as possible. Having said that, the possibility that we may need to
split the library into different files at one stage is another reason why we
opted for providing the library as a .zip file rather than as a .rp from day
one. :-)

[Loren Baxter]

Hey all,

I'm working on putting some of this into a list which we can discuss.  One concern came up - I disagree that we should use the "Page Notes" of masters for documentation.  This is because the page notes get output when the user generates a specification.

In terms of use, I think the masters should be completely self-contained and limited to the actual widgets, not meta-information like name, instructions, versions, or author.  Otherwise our users will have to erase this information manually when generating their deliverables.

I like how the documentation has been done currently: Info on the example pages, keeping it separate from the actual masters while still being accessible (kind of like a help file).

Any thoughts?
-Loren

[victor]

Hi Loren,

That's a good point. The upcoming widget library feature will have an
area separate from the notes for adding name, instructions, versions,
author etc. That information will be available in a tooltip when the
widget is selected in the widgets pane.

[We hope to have a beta soon so you can see what this feature will
look like.]

Victor

[Will]

I am in total agreement with Loren on the documentation issue and
looking forward to the list. Has there been any thought around
identifying areas that need the attention of the community? For
example, should we consider an appendix to each library release that
outlines what we would like to see in future releases of libraries.
Might help folks new to the game (like myself) get an idea where we
can contribute/potential direction of future library releases.

[lukeperman]

Hi all,

I think there are four things here, which need to be separated out:

1. Design Pattern Standardization - A standard for the look and feel
of all widgets in the library. I feel we are fairly close to this with
the recent release, although I plan to make some amends where a couple
of patterns haven't worked so well. I think some form of documentation
around this standard is required for clarity and for future widget
developers. Any input into this list is welcomed, but I feel I should
create the initial list as a starting point as it will reflect the
work already done with the library. I will get this up on the group as
soon as possible. As explained earlier, in the short term I had
expected to 'edit' any submissions so that they conform with the
standard already presented.

2. Widget Documentation - A standard is required for the documentation
of pattern behavior, any reliance on variables, tips on how to edit
the pattern etc. The future update to Axure to allow for custom
widgets will be a real help here. One of my grumbles about Axure is
how hard it is to add annotations to a complete master, rather than
just each individual item within the master. I tend to draw a blank
rectangle behind the master and add any annotations to that! I have
been working on a rudimentary list of ideal annotations for components
within wireframes. I will post this a bit later today, as feedback
from the community here will be very helpful in fleshing that out. At
present this list was just talking to clients and developers - but I
can see the benefit of a standard list of notes that should be
attached to each design master in the library.

3. Identifying Areas of Need - this is a good one. Maybe a thread
should be started to allow people to simply shout for anything they
would like to see added to the library, from which pattern creators
can select from? We should add to the library anything people feel
would be of benefit, but we need to be careful that it doesn't get
bloated with examples, as the goal is to create a best practice
library of common reusable elements, rather than simply being a
demonstration of stuff. The pattern site Welie.com is a good start for
inspiration for the kind of elements we had considered for part of the
library.

4. File Structure - At present we have a single file that appears in a
presentation style. In the future this may be split into multiple
files per category, but I think the format works for now. I foresee
that the library will be something that resides on a hard drive, and
whenever a pattern is required, the 'Import' feature of Axure should
be used to simply import the relevant patterns into the open document.
Alternatively, the pattern library could be used as a blank template
document, in which case some more thought should be given to the
structure of the file. However I think the former seems the most
likely usage. (Especially as it can be a real pain to delete all those
unwanted masters...)


Any thoughts?

I'll get the things I've mentioned above up as soon as possible :)

cheers,
Luke

[Loren Baxter]

Hey Luke,

I started typing this up over the weekend, it might help:

AXLIB Design Library Standards

1. Widget width
   Choose the appropriate size for your widget.  When reasonable, try to standardize to one of these widths for consistency.
   
1. Full: 960px
2. Half: 480px
3. Third: 320px
4. Quarter: 240px
2. Level of Fideltiy
1. Low fidelity.  AXLIB is intended to show functionality and approximate layout.  Visual styling should be minimal, using subtle colors, lines, and contrast to help differentiate between various pieces of content.
3. Level of Interactivity
1. Axure's power lies in its ability to communicate interactivity.  Widgets should include enough interaction to showcase their functionality.
4. Documentation
   Documentation should be separated from the content so that it is not rendered when library users generate Specifications.  Thus, each master should only contain interactions and annotations specific to the widget itself.  Each master will be included in the Pages of Axlib, and documentation will be entered around the master.
   
1. Widget name
2. Author
3. Version (1.0 for first time entries)
   
4. Usage (what the widget is and does)
   
5. Instructions (optional, special instructions on getting the widget to work properly)
6. Variables (optional, if variables are used, give names and explain)
7. Raised Events (optional, if raised events are used, give names and explain)
5. Fonts
1. Standard: 8px Arial
2. Heading 1: 11px Arial (bold)
3. Heading 2: 9px Arial (bold)
4. Strong: 8px Arial (bold)
6. Colors
1. Text: #000
2. Subtle Text: #666
3. Hint Text: Italic, #AAA
   
4. Hyperlinks: Underlined, #00F
5. Background: #FFF
6. Darker Background: #CCC
7. Reverse Color Background: #666
8. Reverse Color Text: #FFF
9. Highlight Background: #FFC
7. Standard Variables
1. AlwaysTrue = ""
   Used to check for an always true condition for triggering interactions.
2. IsLoggedIn = "" - Not logged in
   IsLoggedIn = "1" - Logged in

[luke....@evoke-media.com]

Hey Loren

That's a great start! I'll add my own list and post something further.
Thanks for your input.

Luke

> Hey Luke,
>
> I started typing this up over the weekend, it might help:
>
> AXLIB Design Library Standards
>

> 1. Widget width

> Choose the appropriate size for your widget. When reasonable, try to
> standardize to one of these widths for consistency.

> 1. Full: 960px
> 2. Half: 480px
> 3. Third: 320px
> 4. Quarter: 240px
> 2. Level of Fideltiy
> 1. Low fidelity. AXLIB is intended to show functionality and

> approximate layout. Visual styling should be minimal, using
> subtle colors,
> lines, and contrast to help differentiate between various pieces
> of content.

> 3. Level of Interactivity
> 1. Axure's power lies in its ability to communicate interactivity.

> Widgets should include enough interaction to showcase their
> functionality.

> 4. Documentation

> Documentation should be separated from the content so that it is not
> rendered when library users generate Specifications. Thus, each master
> should only contain interactions and annotations specific to the widget
> itself. Each master will be included in the Pages of Axlib, and
> documentation will be entered around the master.

> 1. Widget name
> 2. Author
> 3. Version *(1.0 for first time entries)*
> 4. Usage *(what the widget is and does)*
> 5. Instructions *(optional, special instructions on getting the
> widget
> to work properly)*
> 6. Variables *(optional, if variables are used, give names and
> explain)*
> 7. Raised Events *(optional, if raised events are used, give names
> and
> explain)*
> 5. Fonts
> 1. Standard: 8px Arial
> 2. Heading 1: 11px Arial (bold)
> 3. Heading 2: 9px Arial (bold)
> 4. Strong: 8px Arial (bold)
> 6. Colors
> 1. Text: #000
> 2. Subtle Text: #666
> 3. Hint Text: *Italic, #AAA*
> 4. Hyperlinks: *Underlined, #00F*
> 5. Background: #FFF
> 6. Darker Background: #CCC
> 7. Reverse Color Background: #666
> 8. Reverse Color Text: #FFF
> 9. Highlight Background: #FFC
> 7. Standard Variables
> 1. AlwaysTrue = ""

> Used to check for an always true condition for triggering
> interactions.

> 2. IsLoggedIn = "" - *Not logged in
> *IsLoggedIn = "1" - *Logged in*