Why doesn't the social software community eat its own dog food and share designs and ideas more openly?
Almost six years ago Tim O’Reilly proposed the phrase “architecture of participation” to describe participatory Web sites and applications that encourage user-driven content, open source contribution models and simple access via APIs. So why are so many of these sites and applications under-designed at the interface and interaction level, not to mention having vaguely architected overall functionality? Many of these sites are relying on the (initial) enthusiasm of users or compelling features to keep and encourage collaboration. What are some of the best practices in more attractive and functional interfaces with clear labels, (usability) tested interfaces, finely crafted workflows and consistent interaction models that both keep early adopters involved and allow for easy bootstrapping for late-comers? This panel will review and discuss examples in designing participatory, community-oriented sites so designers don’t have to re-invent the wheel. The audience is strongly encouraged to suggest designs and bring design problems that can be discussed in Q&A throughout the session.
Questions Answered:
What's the best way to build applications to help form a community of users for voting or rating items?
How do you keep people involved in using the system and contributing to the community?
What are the best designs for (immediate) feedback for discussion and sharing information?
Who has the best atypical interfaces for social computing and what can we learn from them?
Do different community demographics need different interfaces and motivations?
What are the task flows that deisgns should support for social tasks?
Are there specific information architectures for voting and ranking that work best?
What interface devices (points, stars, thumbs up/down, trophies) help people understand ratings the easiest?
What interfaces encourage ranking items into lists?
How should you present suggestions in the most useful way?