Has anyone been asked to create a directory of UI elements?

12 Dec 2007 - 3:16pm
6 years ago
8 replies
478 reads
Mark Richman
2006

I was discussing a new project with someone from our Sales group, and
they asked me how I kept track of fields in case they were dropped
from the actual implementation for some reason. I said that I kept old
versions of the wire frames and usually commented any changes
following the first version.

However, I realized that not only didn't I keep a master list of UI
elements, I'd never actually seen one outside of wire frames.

In my previous life as a systems engineer, this type of directory of
all database and system fields would have very likely been a piece of
the project.

So, does anybody on this list create a deliverable of this nature? If
so, are there specific conditions under which you would do this? Most
of my colleagues just create the wire frames and let them speak for
themselves.

Thanks

Mark Richman
Product Designer
Intelliverse

Comments

12 Dec 2007 - 4:29pm
bminihan
2007

I don't have a hardened process, but for projects that need to build on what
I've done (long term), I tend to deliver the following:
Functioning DHTML prototype connecting all of the graphic assets together
Documented CSS explaining what the key styles are
Palette file listing the colors used in the CSS
Bulleted list of common and unique graphic elements, plus names of their
master files (PNG from Fireworks) and prod files (GIF or JPG)
PNG files containing the last iteration of wireframes or mockups (whichever
is most relevant to the prototype)

I'd say I probably have time to do ALL of the above for about 10% of
projects. Another 30% get the basic gist of the above, missing one or two
items here or there.

I did most of the graphics for my last company's enterprise portal, so I
finally built a web index of all translated buttons, styles and graphic
elements relevant for portlet developers. It turned out to be pretty
popular, and survived about five years. To my knowledge, they're still
using it. Since I quasi-managed most of the redesigns over the years, I
tried to avoid having to replace all of the translated elements we built
over time. It really illustrated how prior planning could have reduced our
being locked into one goofy rounded rectangle button style (which I hated
after about...a month).

Something that would be handy is a little utility that could take a nested
folder containing all of the above and let you document each one in a
tabular form layout, then deliver to the customer in web or PDF form. I'd
pay for that =]

Bryan
http://www.bryanminihan.com

-----Original Message-----
From: discuss-bounces at lists.interactiondesigners.com
[mailto:discuss-bounces at lists.interactiondesigners.com] On Behalf Of Mark
Richman
Sent: Wednesday, December 12, 2007 3:17 PM
To: discuss at lists.interactiondesigners.com
Subject: [IxDA Discuss] Has anyone been asked to create a directory of UI
elements?

So, does anybody on this list create a deliverable of this nature? If
so, are there specific conditions under which you would do this? Most
of my colleagues just create the wire frames and let them speak for
themselves.

Thanks

Mark Richman
Product Designer
Intelliverse

12 Dec 2007 - 4:46pm
Bill Fernandez
2007

Mark--

None of my clients have yet required such a directory of me, but upon
occasion I have found it useful to create one on my own: For example
in a network administration application that I was redesigning the UI
for from the ground up, that had a few hundred configuration settings
that had to be carried over, and maybe a hundred new features that
had to be added. I found that a FileMaker database helped me both in
documenting how each feature worked, in clustering related features
together for the new info design, in making sure nothing got
forgotten, and in keeping documentation about design decisions (e.g.
when a new feature made several previous ones obsolete).

--Bill

At 3:16 PM -0500 12/12/07, Mark Richman wrote:
>I was discussing a new project with someone from our Sales group, and
>they asked me how I kept track of fields in case they were dropped
>from the actual implementation for some reason. I said that I kept old
>versions of the wire frames and usually commented any changes
>following the first version.
>
>However, I realized that not only didn't I keep a master list of UI
>elements, I'd never actually seen one outside of wire frames.
>
>So, does anybody on this list create a deliverable of this nature? If
>so, are there specific conditions under which you would do this? Most
>of my colleagues just create the wire frames and let them speak for
>themselves.

--

======================================================================
Bill Fernandez * User Interface Architect * Bill Fernandez Design

(505) 346-3080 * bf_list1 AT billfernandez DOT com *
http://billfernandez.com
======================================================================

12 Dec 2007 - 4:48pm
Ari
2006

a good design pattern library might include this if you're lucky enough to
have to time to create one.
some tools like Axure allow you to assemble libraries of UI elements you use
in your prototypes and it has a 'Masters' option that allows you to include
them in specs you generate.

On 12/12/07, Mark Richman <markjrichman at gmail.com> wrote:
>
> I was discussing a new project with someone from our Sales group, and
> they asked me how I kept track of fields in case they were dropped
> from the actual implementation for some reason. I said that I kept old
> versions of the wire frames and usually commented any changes
> following the first version.
>
> However, I realized that not only didn't I keep a master list of UI
> elements, I'd never actually seen one outside of wire frames.
>
> In my previous life as a systems engineer, this type of directory of
> all database and system fields would have very likely been a piece of
> the project.
>
> So, does anybody on this list create a deliverable of this nature? If
> so, are there specific conditions under which you would do this? Most
> of my colleagues just create the wire frames and let them speak for
> themselves.
>
> Thanks
>
> Mark Richman
> Product Designer
> Intelliverse
> ________________________________________________________________
> *Come to IxDA Interaction08 | Savannah*
> February 8-10, 2008 in Savannah, GA, USA
> Register today: http://interaction08.ixda.org/
>
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> Unsubscribe ................ http://www.ixda.org/unsubscribe
> List Guidelines ............ http://www.ixda.org/guidelines
> List Help .................. http://www.ixda.org/help
>

--
--------------------------------------------------
www.flyingyogi.com
--------------------------------------------------

12 Dec 2007 - 4:53pm
Bill Fernandez
2007

Bryan--

I actually did something like that once when I inherited (and had to
extend) a large set of document-fomrat icons. On the Mac I wrote an
AppleScript script that read through the folders of icons and copied
the graphics and the names into a FileMaker database. This became
the basis of a large icon database that grew over the years. When I
needed to publish lists of icons I could search, sort, then print to
PDF.

--Bill

At 4:29 PM -0500 12/12/07, Bryan Minihan wrote:
>Something that would be handy is a little utility that could take a nested
>folder containing all of the above and let you document each one in a
>tabular form layout, then deliver to the customer in web or PDF form. I'd
>pay for that =]

--

======================================================================
Bill Fernandez * User Interface Architect * Bill Fernandez Design

(505) 346-3080 * bf_list1 AT billfernandez DOT com *
http://billfernandez.com
======================================================================

12 Dec 2007 - 4:54pm
Dan Brown
2004

Mark,
Not sure if this addresses your question... These days, we're making
modular wireframes: creating individual screen components and
assembling wireframes from those "lego bricks". As part of that
process, we usually generate a spreadsheet of all the components we
want to create. This allows us to validate the list before diving in
and wireframing all of them.

One advantage to this modular approach is that we can then quickly and
easily create a document that specifies behaviors/details for each
component -- a component catalog. Imagine that each component is
wireframed separately in individual Visio (or whatever format you use)
files. We simply drop the component into a specification document
instead of a screen template. (We call those "views".)

As for specific conditions, the component catalog is ideal when we
create a wide set of components for use in a variety of circumstances
that are not covered by all the wireframes/templates. That is, the
range of wireframes does not include every possible component. There
are other situations, but that one came to mind...

-- Dan

On 12/12/07, Mark Richman <markjrichman at gmail.com> wrote:
> I was discussing a new project with someone from our Sales group, and
> they asked me how I kept track of fields in case they were dropped
> from the actual implementation for some reason. I said that I kept old
> versions of the wire frames and usually commented any changes
> following the first version.
--
| work: eightshapes.com
| book: communicatingdesign.com
| blog: greenonions.com
| talk: +1 (301) 801-4850

12 Dec 2007 - 5:05pm
Mark Richman
2006

When I originally posted this I was thinking of distinct data elements
such as order type, customer number, credit card number, which are UI
fields as well as database fields.

However, UI elements would more appropriately reference widgets and
style elements.

I love Dan's solution, which is kind of like using a standard widget
guide and customizing it as needed for an individual project. If I
create a document like that, it usually takes shape throughout the
life of the project. Of course it makes more sense to get it done
early and refer to it as needed.

Mark

On Dec 12, 2007 4:54 PM, Dan Brown <brownorama at gmail.com> wrote:
> Mark,
> Not sure if this addresses your question... These days, we're making
> modular wireframes: creating individual screen components and
> assembling wireframes from those "lego bricks". As part of that
> process, we usually generate a spreadsheet of all the components we
> want to create. This allows us to validate the list before diving in
> and wireframing all of them.
>
> One advantage to this modular approach is that we can then quickly and
> easily create a document that specifies behaviors/details for each
> component -- a component catalog. Imagine that each component is
> wireframed separately in individual Visio (or whatever format you use)
> files. We simply drop the component into a specification document
> instead of a screen template. (We call those "views".)
>
> As for specific conditions, the component catalog is ideal when we
> create a wide set of components for use in a variety of circumstances
> that are not covered by all the wireframes/templates. That is, the
> range of wireframes does not include every possible component. There
> are other situations, but that one came to mind...
>
> -- Dan
>
>
>
>
> On 12/12/07, Mark Richman <markjrichman at gmail.com> wrote:
>
> > I was discussing a new project with someone from our Sales group, and
> > they asked me how I kept track of fields in case they were dropped
> > from the actual implementation for some reason. I said that I kept old
> > versions of the wire frames and usually commented any changes
> > following the first version.
> --
> | work: eightshapes.com
> | book: communicatingdesign.com
> | blog: greenonions.com
> | talk: +1 (301) 801-4850
>

12 Dec 2007 - 6:55pm
Todd Warfel
2003

We've been using a similar approach for about 2 years now and found it
to be extremely effective and productive. It's taking wireframing/
patterns to the level that software development is—object/pattern based.

On Dec 12, 2007, at 4:54 PM, Dan Brown wrote:

> These days, we're making
> modular wireframes: creating individual screen components and
> assembling wireframes from those "lego bricks". As part of that
> process, we usually generate a spreadsheet of all the components we
> want to create. This allows us to validate the list before diving in
> and wireframing all of them.

Cheers!

Todd Zaki Warfel
President, Design Researcher
Messagefirst | Designing Information. Beautifully.
----------------------------------
Contact Info
Voice: (215) 825-7423
Email: todd at messagefirst.com
AIM: twarfel at mac.com
Blog: http://toddwarfel.com
----------------------------------
In theory, theory and practice are the same.
In practice, they are not.

13 Dec 2007 - 2:41am
bhakti भक्ति
2006

we do not have a library of UI elements as of now. But its been quite some
time now that we have initiated the process of having a UI library
containing most of the UI elements. It is essential:
1. As we have team of UI designers working on same product.
2. We can share these elements as standard with the devs for
functionalities/features that do not have prototypes or mocked up work
flows.
3. Easy for the new UI designers to use these components.
4. going further we will also have a UI component's gallery like the AJAX
controls, having a repository will help I believe.

Though there was no request from the client side for the UI components.

~ Bhakti

Syndicate content Get the feed