launchpad developmentLightning talk notes
AJAX über alles
Most everything we do should be AJAX. Corollary: Webservice should rule most everything. Corollary: we should dump old Zope and Launchpad form machinery, and we should have to defend why we need to build a given non-AJAX page for a given feature.
- For text-only browsers, we need bug reporting, bug reading, and...? There is an email interface for people who are on a text-only interface.
- For Google/SEO we need bugs, projects, and...?
- We need an accessibility story but YUI 3 was built with ARIA ("Accessible Rich Internet Applications") support.
This can give us faster and more fun development. Also, when we make the webservice the way we deliver to the browser, it opens up the same mechanisms to other platforms, such as the desktop (GroundControl), Android, iOS, and so on.
(No progressive enhancement, no graceful degradation)
(Pages are for context; overlays are for aspects of it)
Functions Are Pythonic Too
Python is a multi-paradigm language. Object-oriented is one approach. Sometimes, and maybe more often than we as a team expect, functions are nice.
- They are unit testable in isolation, often without stubs.
- Ideally they are factored so that they have nice, clear contracts, which are typically simpler than that of objects.
- They are friendly to idempotence, which is a characteristic that can make it easier to reason about systems.
- They don't have state, which can make it easier to reason about systems.
We are not using Java: not everything has to be an object in Python. Functions are idiomatic. Don't forget them, and don't reject them.
Prototyping Goals with User Documentation
Prototyping with user documentation works. If doctests are the bathwater, one of the babies might be user documentation as design tool. I have not used that tool lately, and have come to regret it. I hope to try some new variation of the basic idea again.
Prototyping can be expensive and hard. It still is cheaper than building a full system and getting it wrong.
One approach to getting some of the benefits of prototyping is mockups. We do that now with screen mockups for user-facing features. You can also make API mockups, which we sometimes do too.
You can combine both or either of these with trying to make user documentation mockups. These can end up feeling like a next step past a screen or API mockup.
How would a user accomplish each task of your feature? In your documentation mockup, describe each task in a friendly way to your potential user. This allows you to describe the workflow you intend, maybe the error handling you propose, and/or maybe other parts of the story.
When you are writing them, you are telling the stories of your ideas to yourself. Listen. Do they make sense to you? Do they make sense to your colleagues? Do they make sense to your stakeholders?
I and others have found this to provide a window onto your ideas that can let you think critically about them, from the perspective of your users. My experience with this technique, and the experience I've seen with others, has been very good.
Ideas not for the talk
We should do a better job on really defining completion requirements with SMART goals in our LEPs. "We are completely done when..."
For feature work, try week timeboxes, with end-of-week demos and review of plan and goals. Ship (deploy) every week.
