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
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.
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.
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/
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. :-)