0.4 Retrospective

About the Retrospective

The Fluid 0.4 retrospective meeting is an opportunity for community members to get together and talk about what worked well and what needs to be improved in our shared design/development process. Based on this reflection, we'll come up with specific actions and appoint a "champion" for that task. A champion is not necessarily expected to accomplish the action, but rather to help remind people of the importance of the goal and ensure that it stays on our radar.

Agenda

1. Look back at the highlights from the past two months.

2. Collaboratively answer these questions with a backwards looking perspective:

   • What went well?

   • What didn't go well?

   • What did we learn?

   • What still puzzles us?

3. Collaboratively come up with specific, concrete actions

Design highlights from 0.4

Lots of outreach

• Presentations on Patterns, design process, Fluid overview, etc.

New components: Pager and InlineEdit

• Went through a whole development cycle for both components:

  • Contexts of use

  • Storyboards and use cases

  • Design specifications

  • Several drafts of design patterns for each component

Patterns Library

• Well on the way to moving patterns over to the OSDPL content management system

Component Matrix

• Prioritizing components based on pain points, user research, and strategy alignment with communities

Wiki

• Tons of improvements to the wiki

• Changes to UX toolkit

• Component pages

• Navigation improvements

• How to contribute/Current Needs

User Testing

• Second round of testing for Uploader, Layout Customizer, and more

• Testing protocols for Pager and Inline Edit

Contextual Inquiry

• Plugging away at our research findings

• Focus is on personas and getting those out to the community

Process Definition

• How we do design and how it intersects with development

• Team design reviews: devs and designers talking about designs in progress

• Design standup meetings

Development highlights from 0.4

Uploader

• completely changed the progress bar

• added keyboard a11y and ARIA

• allowed for multiple instances on a page

• integration with ATutor

Inline Edit

• brought out the of sandbox - tests, bug fixes etc.

• ARIA support added

• examples were created

• that-ified

• support for simple multiple inline edit creation

• partial self rendering support

Pager

• sketched out the component in a drawing and in code

Reorderer

• improved ARIA for the layout customizer

• integration with ATutor

Keyboard a11y plugin

• API changes: closer alignment with jQuery UI style

• that-ified

Other

• Our first focussed QA effort

• first pass at the template renderer

• defined some of the component framework - fluid.container, defaults, that etc.

• upgrade to jQuery 1.2.6

• technical documentation

• tutorials

• 0.4 beta release

• 0.4 release

What went well?

• Clear requirements and priorities for this release

• Discussions happened alongside coding good

• Design reviews with the entire team: helped ensure we were getting feedback and having those conversations across team members

• Clear work list with reasonable expectations of timelines: dashboard of sensibly prioritized tasks

• Bug fixing happened efficiently and quickly

• Current needs page was helpful

• Having additional architectural resources available with Antranig on board

• Dedicated QA resources made a huge impact on our focus and dedication towards squashing bugs

• Having Jess here as a dedicated project manager

• Design process is getting clearer and more approachable

• Better usage of JIRA to help coordinate

• More user testing has been useful

• Use of storyboards and storycards

• Design standup meetings are helpful

• Project management is awesome

• Depth of thinking in terms of JavaScript and architecture

• Flexibility

• Did we say project management?

• Using JIRA to help with tracking and prioritization

• Use of the IRC channel made it easier to have group discussions

What didn't go well?

• Documentation left until towards the end of the release

• Our communication load was a bit overwhelming

• Distracting Colin

• Need to get components into real world applications: they're not done until they're integrated

• Can use communications media better; recognizing how to use them and also not get distracted; not reacting negatively to new tools

• Design standup is a double-edged sword; others are missing out on critical information

• IRC can be overwhelming

• Didn't get a chance to polish and share our personas and other CI information

• Not enough time to do paired designing

• Communication: still feel left out from the conversations at one location or another

• The ability to use tools to communicate better and more clearly: not randomly or gratuitously, but for their effectiveness

• Travel and vacations can make coordination harder

What did we learn?

• How to use IRC effectively, and that it does have a lot of benefits

• How to use the wiki more effectively for both working documents and "fully baked" documents

• Learned how to use JavaScript safely and reliably with that-ism

• Starting to learn what types of components we can build

• Learned a lot about jQuery

• Learned how messy the browser can be, and strategies for how to cope

• Learned about ARIA's strengths and weaknesses

• Lots about testing

• IRC is useful for communication

• Learned how sometimes code isn't the only way to contribute to the technology

• Learned how to do right-left aligned tables in Confluence

• Lots and lots about JavaScript

• How to use JIRA and Confluence together to help organize the team roadmaps

• Communication strategies

• Design patterns, libraries, and the rich variations on patterns

• How to understand the designer and developer perspective, and how to unify them

• Putting Fluid components into a working application is a whole other task: lots to do!

• How to work in a distributed team: sharing ideas, using a common language, prototyping tools

• How to use OmniGraffle

• How to use Drupal

• How to work as a design team and communicate with developers

• Learning how much we don't know

• Different types of integration help a lot in evolving a component

• Complexity of the environment: us and our friend projects

• The value of pair programming

What still puzzles us?

• How to juggle everything

• How to work over multiple time zones

• Figuring out how to get focused time

• Exactly where we're going in terms of integration of components in applications

• Still puzzled by how users really interact with assistive technologies

• How to teach the concepts of functional programming to our wider user audience

• Puzzled by how open source communities organize themselves, both positively and negatvely

• Addressing multiple audiences: for the OSDPL, how do we satisfy both developers and designers?

• How to have everyone embrace communications tools

• How to make the best pattern library possible

• How to be more efficient in a distributed community

• Where the JavaScript web app development model is moving over the next 5 years

• How we fit with other projects and how they see us fitting with them

• UX iteration planning is puzzling

• How to keep track of conversations and putting people into a position of being a component "shepherd"

• How to keep people communicating in a project where communicating is essential

• How to effectively user test our technical documentation

Actions