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
- Look back at the highlights from the past two months.
- 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?
- 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
Action |
Champion |
More retrospectives |
Justin |
Whiteboarding tool |
Jonathan |
Templates for component design pages |
Anastasia |
Design team on IRC |
Michelle & Jonathan |
Polish up our research findings |
|
Automated testing |
Michelle |
Get components into other apps |
Colin |
Get other people creating components |
|
Bring in more a11y into design process |
|
Share out personas |
Allison |
Try out Balsamiq for prototyping |
|
How to contribute patterns |
Jonathan |
More paired designing |
Daphne |
Put things we've learned into practice |
|
Revisit this page |
Jess, Colin, Daphne |
Help people understand our processes |
Jacob |
Find a better way to release tech docs |
Colin |
Create a good Fluid primer: tech and more |
Anastasia |
Move the standup meeting to a later time |
Jess |