Do you ever have one of those stretches where your head is just overflowing with ideas - things to build, to write, to learn, to do?
I’m in one of those at the moment, but I’m so fully booked by existing commitments that I can’t take any action on most of ‘em - so I write them down as I can, and hope that they’ll still be appealing when I get through all the work I already have to do. Frustrating.
So here’s a question: how do you design your process artifacts to take progressive enhancement into consideration? (Wow, I think I just used my monthly quota of buzzwords.) In other words, how do you create wireframes, comps, and buildouts that show 1) the structure and look of a site at full-functionality, with fancy JavaScript and whatnot all over the place, as well as 2) the same site as it functions without the scripting?
Take Rails 2’s scaffold-generated index action, for instance. When you first create it, you get a list of records with view, edit, and destroy links - those destroy links, however, are wholly JavaScript-dependent; on clicking them, the page creates a form with a couple of hidden fields (including _method=”delete”, to get Rails to treat the request as if it came in via the HTTP DELETE method), requests confirmation from the user, and submits the form.
Without JavaScript, on the other hand, you’d have to have the form already on the page - which is easy, and is transparent from the point of view of the artifacts I’m talking about - but the confirmation question is different. Do you have to change the visible form to include, say, a checkbox that must be selected to confirm the delete? Or do you insert a new page in the process - so on clicking the delete link, you get a new page back asking you to confirm?
This may not seem so intimidating, but it is the simplest case. Consider the case where you want to show and hide various sections of a page as the user needs them. Without JavaScript, this would require full-page loads - which means that your design process will have to accommodate that by either revising the requirements or splitting the functionality across multiple new pages. This is easy enough to do in Rails, by using respond_to to return full pages for HTML requests and partials for JS requests, but means that your design documents will have to account for just that many more possible states.
This question is obviously closely-related to that of representing Ajax and other dynamic functionality in your design process, so it’s entirely possible that a satisfactory answer to that problem will work here, too - but I’ve yet to see a really good solution in that case, either. Any comments?
(photo from cfox74 on Flickr)
Updated!
When preparing to merge a working branch back to master (so that you can push it up to your SVN repository), the following process may be helpful:
> git checkout -b working
[work work work]
> git commit -m “helpful message”
[work work work]
> git commit -m “another helpful message”
> git svn rebase (pull down others’ updates - this is the updated step)
> git checkout master
> git svn rebase (pull down others’ updates)
> git merge –squash working
> git commit
[delete metadata, leave helpful messages]
> git svn dcommit
The output of all that is an SVN commit reading:
Squashed commit of the following:
another helpful message
helpful message
If you supply an explicit commit message to the last git commit (the one in bold), however, it will override your squashed messages and your SVN log will show only the final outcome, instead of all the steps you took to get to it. Of course, you could also leave the metadata from the squash - but that ends up generating a lot of noise in the SVN log.
Updated!
If your working and master branches are on different SVN revisions, you’re more likely to run into trouble during the merge, so it seems like a good idea to rebase both before trying to combine the two.
Thanks to my coworker Clinton for this addition!
