Christopher Alexander (born October 4, 1936 in Vienna, Austria) is an architect noted for his theories about design, and for more than 200 building projects in California, Japan, Mexico and around the world. Reasoning that users know more about the buildings they need than any architect could, he produced and validated (in collaboration with Sarah Ishikawa and Murray Silverstein) a "pattern language" designed to empower any human being to design and build at any scale. Alexander was a licensed contractor and architect in England. In 1958 he moved to the United States, and has lived in Berkeley, California from 1963 until the present. He is professor emeritus at the University of California, Berkeley.
Tuesday, December 18, 2007
Design pattern documenting standards
The documentation for a design pattern describes the context in which the pattern is used, the forces within the context that the pattern seeks to resolve, and the suggested solution.[4] There is no single, standard format for documenting design patterns. Rather, a variety of different formats have been used by different pattern authors. However, according to Martin Fowler certain pattern forms have become more well-known than others, and consequently become common starting points for new pattern writing efforts.[5] One example of a commonly used documentation format is the one used by Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides (collectively known as the Gang of Four) in their book Design Patterns. It contains the following sections:
- Pattern Name and Classification: A descriptive and unique name that helps in identifying and referring to the pattern.
- Intent: A description of the goal behind the pattern and the reason for using it.
- Also Known As: Other names for the pattern.
- Motivation (Forces): A scenario consisting of a problem and a context in which this pattern can be used.
- Applicability: Situations in which this pattern is usable; the context for the pattern.
- Structure: A graphical representation of the pattern. Class diagrams and Interaction diagrams may be used for this purpose.
- Participants: A listing of the classes and objects used in the pattern and their roles in the design.
- Collaboration: A description of how classes and objects used in the pattern interact with each other.
- Consequences: A description of the results, side effects, and trade offs caused by using the pattern.
- Implementation: A description of an implementation of the pattern; the solution part of the pattern.
- Sample Code: An illustration of how the pattern can be used in a programming language
- Known Uses: Examples of real usages of the pattern.
- Related Patterns: Other patterns that have some relationship with the pattern; discussion of the differences between the pattern and similar patterns.
Design patterns pros and cons
Design patterns can speed up the development process by providing tested, proven development paradigms. Effective software design requires considering issues that may not become visible until later in the implementation. Reusing design patterns helps to prevent subtle issues that can cause major problems, and it also improves code readability for coders and architects who are familiar with the patterns.
Often, people only understand how to apply certain software design techniques to certain problems. These techniques are difficult to apply to a broader range of problems. Design patterns provide general solutions, documented in a format that doesn't require specifics tied to a particular problem.
Design patterns are composed of several sections (see Documentation below). Of particular interest are the Structure, Participants, and Collaboration sections. These sections describe a design motif: a prototypical micro-architecture that developers copy and adapt to their particular designs to solve the recurrent problem described by the design pattern. A micro-architecture is a set of program constituents (e.g., classes, methods...) and their relationships. Developers use the design pattern by introducing in their designs this prototypical micro-architecture, which means that micro-architectures in their designs will have structure and organization similar to the chosen design motif.
In addition, patterns allow developers to communicate using well-known, well understood names for software interactions. Common design patterns can be improved over time, making them more robust than ad-hoc designs.
Caveats
In order to achieve flexibility, design patterns usually introduce additional levels of indirection, which might complicate the resulting designs and hurt application performance.
Design pattern from Wikipedia
Patterns originated as an architectural concept by Christopher Alexander (1977/79). In 1987, Kent Beck and Ward Cunningham began experimenting with the idea of applying patterns to programming and presented their results at the OOPSLA conference that year.[1][2] In the following years, Beck, Cunningham and others followed up on this work.
Design patterns gained popularity in computer science after the book Design Patterns: Elements of Reusable Object-Oriented Software was published in 1994 (Gamma et al.). That same year, the first Pattern Languages of Programs Conference was held and the following year, the Portland Pattern Repository was set up for documentation of design patterns. The scope of the term remained a matter of dispute into the next decade.
Although the practical application of design patterns is a phenomenon, formalization of the concept of a design pattern languished for several years.[3]
Design pattern (computer science) - Wikipedia, the free encyclopedia
All Patterns - Yahoo! Design Pattern Library
Design pattern design according to Yahoo...
What's a Pattern?
A pattern describes an optimal solution to a common problem within a specific context.
From the IAWiki:
Patterns are optimal solutions to common problems. As common problems are tossed around a community and are resolved, common solutions often spontaneously emerge. Eventually, the best of these rise above the din and self-identify and become refined until they reach the status of a Design Pattern.Each pattern has four primary components:
- a title
- a problem
- a context
- a solution
Because a picture is worth a thousand words, the patterns also have a "sensitizing example" (we have tried to include a screen shot along with an animation example of the interaction) that visually represents the pattern. Rationale and Accessibility concerns are also captured in the pattern.
Additionally, each pattern will have a corresponding blog entry (located at yuiblog.com). This is where we encourage feedback and conversations around the individual patterns. RSS subscriptions per pattern are also available.
The Lifecycle of a Pattern
At Yahoo!, a pattern most often comes into the library via the traditional design process. Within the context of a product design cycle, a solution to the common problem is created.
The solution, within the context of a property or specific product is tested and iterated. Design research and designers collaborate and will test the range of low-fidelity prototypes to final product usability testing. Data is collected and those results inform the solutions offered in the pattern.
The designer of the solution, or the central Yahoo! UED (User Experience & Design) group recognizing solutions to common problems across the network, writes the pattern for submission to the library. Specific research supporting the pattern is flagged in support of the solution. Additionally, the central UED design research team periodically reviews research from all across Yahoo! and makes recommendations for refinements to the pattern. The central UED research team also conducts baseline research on many of the UI components available via the pattern library and the Yahoo! User Interface Code Library.
The pattern is then edited, published, reviewed and labeled with an adherence rating.
Our ratings range from*:
- In progress
- Working solution
- Best Practice
- The Yahoo! Way
The adherance rating gives the design team a sense of the maturity of the design solution as well as the flexibility for deviation from the pattern.
As designs evolve and technologies change that enable new solutions to emerge, the pattern library evolves as well.
Yahoo! Design Pattern Library
Yahoo has a Design Pattern Library, part of the Yahoo! Developer Network
Welcome
Welcome to the Yahoo! Design Pattern Library. We've just reorganized the navigation scheme for our patterns What's a Pattern?
A pattern describes an optimal solution to a common problem within a specific context. more...Recent Patterns see all...
- Alphanumeric Filter Links
The user needs the ability to look up information alphabetically within a large data set.- Animate Transition
Designer needs to communicate that an object is changing its spatial relationship within the page.- Calendar Picker
User wants to find or submit a particular piece of information based on a date or between a date range.
- Collapse Transition
The designer needs to communicate that an object is no longer of primary importance.- Drop Invitation
Designer needs to indicate valid candidate drop sites during a drag and drop operation.- Expand Transition
Designer needs to show the detail of an object in its context or reveal a previously collapsed object.
- Fade In Transition
Designer needs to communicate that an object is being added to the page or application.- Page Grids
Web sites have a need for consistency amongst common page elements.- Self Healing Transition
Designer wants to show that an object has been removed from a list of objects.
- Slide Transition
The designer wants to bring new content into the page and would like to communicate the additional content's relationship with other items on the page.- Tool Tip Invitation
Designer needs to cue the user about what will happen if they click the mouse on the hovered object.- Vote to Promote
User wants to promote a particular piece of content in a community pool of submissions.Join Our Design Pattern Community
There's two ways to talk back. First, we blog our patterns. Second, we have a forum for general discussion.
» Check out Updates at yuiblog.com
» Join the Discussion at the Yahoo! Pattern Group
Yahoo! UI Library
Need code?
Get our open source Ajax library.
The pattern library :
A user needs to
Copyright © 2005-2007 Yahoo! Inc. All rights reserved.
Privacy Policy - Terms of Service - Copyright Policy - Job Openings
User Interface Design Patterns: Introduction
Another good collection of UI patterns
Introduction
Search
Data Views
Storages
Selecting and Manipulating Objects
Time
Hierarchies and Sets
Save and Undo
Updated 16.09.2003
by Sari A. Laakso,
email salaakso@cs.helsinki.fi
About the Book - Designing Interfaces
A good collection of UI Patterns.
Overview
About the Book
Introduction
About PatternsOrganizing the Content
Two-Panel Selector
One-Window Drilldown
Wizard
Extras On Demand
Intriguing BranchesGetting Around
Clear Entry Points
Global Navigation
Color-Coded Sections
Animated TransitionOrganizing the Page
Visual Framework
Center Stage
Titled Sections
Card Stack
Closable Panels
Movable Panels
Diagonal Balance
Responsive Disclosure
Responsive Enabling
Liquid LayoutCommands and Actions
Action Panel
Smart Menu Items
Progress Indicator
Multi-Level Undo
Command HistoryShowing Complex Data
Overview Plus Detail
Row Striping
Sortable Table
Jump to Item
Cascading Lists
Tree-TableGetting Input From Users
Forgiving Format
Fill-in-the-Blanks
Input Hints
Input Prompt
Dropdown Chooser
Illustrated Choices
Good DefaultsBuilders and Editors
Edit-in-Place
Smart Selection
Composite Selection
One-Off Mode
Constrained ResizeMaking It Look Good
Deep Background
Few Hues Many Values
Corner Treatments
Monday, April 30, 2007
About User Interface Patterns
About User Interface Patterns is my blog about User Interface Patterns.
Subscribe to:
Posts (Atom)
Posts
