0.5 Retrospective
About the Retrospective
The Fluid 0.5 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 we'll volunteer to be champions for specific tasks. 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 on the actions and results from the last retrospective.
- 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
Actions we implemented
- More retrospectives
- Design team on IRC
- More paired designing
- Put things we've learned into practice
- Help people understand our processes
- Move the standup meeting to a later time
- Polish up our research findings
Actions we partially implemented
- Whiteboarding tool
- Automated testing
- Get components into other apps
- Bring in more a11y into design process
- Share out personas
- Revisit this page
- Templates for component design pages
Actions we didn't implement
- Get other people creating components
- Try out Balsamiq for prototyping
- How to contribute patterns
- Find a better way to release tech docs
- Create a good Fluid primer: tech and more
Design highlights from 0.5
Wiki
- Tons of improvements to the wiki
- Repeatable, easy to navigate, structure to component pages (ex.Inline Edit Family of Components)
- New component icons for web presence
- Improvements to Fluid Website
Research Models
- Personas released
- Frequency added to "Use Case Frequency Matrix"
Components
- Renaming Reorderer and Inline Edit families
- Began work on component keyboard interaction summary table
- Simple Text Inline Edit in Section Info Demo
- Began working with Michigan to integrate Reorderer and Date Picker in several places in Sakai
- List Reorderer design started
- Date Picker designs making crazy progress
- Uploader design enhancements based on user testing and revisiting the design framework
- Layout Reorderer user testing and performance improvements based on results
OSDPL
- Architecture improvements continue to be made on the OSDPL
- Accessibility improvements based on review
- Governance final
- Began defining "How to Create a Design Pattern"
Other
- Shared out and began using design framework (continual improvements)
- Skype team chat
Development highlights from 0.5
Framework
- DOM binder implemented
- events system in place
- skinning system started
Reorderer
- API's changes and migration tutorials
- replaced jQuery ui.droppable which led to speed and consistency improvements
- Safari support improvements
- integration with uPortal
Uploader
- uploader 2 work begun
Other
- functional examples
- 0.5 beta release
- 0.5 release
- jQuery accessibility started
What went well?
- Framework: it's here! And more importantly, it's not framework for framework's sake; our components evolved alongside it, and their needs drove its design
- The Infusion 0.6 roadmap was created early: well before we started
- Renaming and reconsidering the component families was effective
- Implemented the design framework tasks and actually used them: nice to have a big picture in mind
- Date picker designs started
- Designer Skype chat is really useful
- Wiki reorganizing is nice, pages are looking a lot cleaner
- Improvements to the Reorderer are great and have led to improved integration with Sakai and uPortal
- Communication on list and on the chats have been really incredible
- Great to have the VULab integrated into the community: having Blake help with OSDPL, for example
- Release process is really fun and effective: fast, energetic bug fixing
- Seeing components get integrated into Sakai
- Collaboration with Michigan was really effective and thoughtful
- Lots of "just do it" tasks accomplished: increasing confidence in our work and how it fits into other tasks
- Getting more comfortable expressing ourselves visually: eg. progress indicators, component families, framework
- Lots of positive feedback about Infusion 0.5
- Perhaps we bit off more than we could chew, but this wasn't necessarily a bad thing: we pushed through with a very solid release
- Justin's contribution with QA and community coordination: he's quickly catching issues as they arose, and shared them out
What didn't go well?
- Would have been better if PreferAble had been in the design cycle for a little longer.
- Documentation and communication about the framework could have been better: we should have taken the time to write and talk more about the framework as we coded it
- Scoping: being realistic about what we can do in a particular release
- Bug wrangling near the end was a real challenge: too much scope for the release?
- Restructuring the wiki was a challenge: content got buried accidentally
- Scheduling is always a challenge
- Automated acceptance testing has been a real struggle: a lot slower than we would have hoped for
- Communication: signal/noise ratio
- Framework was moving too quickly without documentation: was hard to play catch up
- Planning is really good, but we can still improve on it: design and development more in sync
- Long-term planning in JIRA can be time-consuming
- Still not doing enough quick visualization of our work, community, code, and designs
- There's still room to improve our communication: this will be a continual problem, but is a good thing
- Left Reorderer tests failing for too long
What did we learn?
- The jQuery UI community is a fun place to play
- How to collaborate with partners; how communities are managed; details about our framework as it emerged
- Talking with other people and other open source communities
- how the design process fits together
- some of our work happens in sprints and some are distance runs
- some of the early activities in design are very important.
- speak up about frustrations early and come up with solutions
- trying to do too much work at one time causes chaos and rubble
- Reminded once again how nice it is to build UIs in a dynamically typed language: views, events, and callbacks just fit
- Learned about co- and contra- variance in OOP: interesting, but not that interesting
What still puzzles us?
- How people are going to pick up our stuff and use it in the real world
- How we have component leads that aren't bottlenecks: how to share our work better
- How to satisfy multiple audiences for the wiki and OSDPL
- How to implement testing strategies, and getting people involved
- Where is collection space going?
- How do we satisfy different audiences?
- How do we make our sprints less painful and less frequent?
- How do we make our work more of a distance run that culminates in a release?
- How do we make design work for components that live in different problem spaces? Personas are an example of the difficulties.
- The event framework is puzzling
- How do we get all of 0.6 done with the distraction of a face to face
- What is the future of Fluid?
- What does the full extent of our declarative approach look like for setting up components?
Actions
Action |
Champion |
|---|---|
Come up with a documentation strategy: how to keep it up to date, archiving, etc. |
|
Bring up issues as soon as they come up: communicate about problems or messiness early |
|
Create ways to ensure the design team is more in touch with bugs and issues |
|
Code and framework "heads up" emails out to the list early and often. Echo conversations back out to the list. |
|
Help others build Fluid components |
|
Documentation: How to contribute patterns? |
|
Automated UI testing |
|