 |
« | Week of Sep 14 | < | Individual Entries | > | Week of Sep 28 | » |  |
 |
 |
The Problem with Data Objects
patterns, software development
September 27, 2003, 04:43 PM
I've been working on the code for Newsable a lot recently, and I'm coming across a problem I confronted when working on EE way back in my code monkey days (about two years ago). The problem relates to a software design pattern known as Data Objects.
Data objects are intended to provide a consistent representation for domain data in a multitiered architecture (in fact, often the cross-cutting concern I mentioned in that earlier post, correctness checking, is implemented in these sorts of objects). Basically, you don't want to give all your code direct access to the persistence layer, but you don't want to be passing around your domain data as primitive types or layer-specific classes (along with all the ugly conversion code) either. So you standardize on an object model for your domain data and use that consistantly throughout the system. Generally the persistence layer is responsible for mapping this object model to a relational datastore.
The problem is that you frequently need many "views" of the data in order to generate the user-interface screens, and it can be hard to predict exactly what data will be necessary for each screen unless you can guarantee that all the screen designs will be fixed in advance (often not true, since design is iterative). Even then, you may find that you need a wide variety of views to fulfill the specifications. This becomes a problem when you need to create a large number of classes to represent these views; for instance, in Newsable's design I have classes for Users, Feeds, and users' Subscriptions to feeds. Should a Subscription contain the User and Feed objects that make it up? Probably, but should a User then contain all of her Subscriptions? That would be helpful for listing the feeds for the "Edit Sources" screen, but wasteful when I just want a User to authenticate their username and password, for instance. And this is only a simple example; EE had a particular series of screens that I calculated would require 12 different view classes for the same collection of data if I developed custom objects that only returned the data necessary for its screen.
I remember seeing a pattern in EJB Design Patterns that involved using hashtables instead of objects for situations such as these to provide for more flexible data definitions (although this also eliminated type safety, of course). Maybe in my next system I'll give that idea a shot if it seems to be appropriate.
Small Groups for Design Critiques
design, processes & methodologies
September 25, 2003, 11:09 PM
In VIID today, we divided up into small groups to discuss our design sketches for the second project with members of the class who were not on our project teams. I wound up in a group with just Kerry, although Jodi and Bilge both dropped by during the session to offer their comments on both of our designs.
This turned out to be a pretty effective format for refining and improving our design ideas. My group got a lot of great feedback that has really helped us pull together the several disparate design solutions that we'd been kicking around before. We came out of that session with much more direction than we'd had going into it, which is something I can rarely honestly say about a class meeting.
Dana and I are discussing the possibility of attempting to bring this format into Newsable as another solution to the open source and usability problem. We hope to set up an appropriate online virtual environment for developers and usability professionals / designers (we're calling this group "usables", which I assure you was entirely Dana's idea) to brainstorm, test, and critique new suggestions and designs. We hope this will form the kind of small groups with small group size, high task valence, and high senses of group identity that previous social science research has found to greatly increase quality contribution.
It's an amazing experience to be working with Dana. So far she's brought much more focus to the project than I've had all summer as well as some great new ideas that I would never have come up with on my own.
Posted by Dana Gelman on September 26, 2003 at 12:33 AM
aawww. that's so sweet. you know i am new to the world of blogging -- so i can't wait to start using newsable to agregate my blogs (or my friends' blogs) -- no news, just blogs.
btw, what is a trackbacK? i'm to chicken to try it... d
Posted by Micah Alpern on September 26, 2003 at 03:19 PM
Rob, you should point out that your talking about Dana Gelman and give her a link.
She deserves her props :)
ps - you might also find this essay by Scott Berkun interesting.
Posted by Rob on September 26, 2003 at 04:19 PM
You're right, Micah, I should have linked to the Master's page. Dana, you need to make a web site so I can link to your "real" url; I forget to do that with you webless ones sometimes ;).
Email Rob:
Redesigning Scheduling
aesthetics, design
September 22, 2003, 11:58 PM
Our first assignment in Visual Interface and Interaction Design (a.k.a. "Jodi's class") was due last week. This was my first attempt at real, live interaction design (well, my first intentional attempt), so I'm documenting it here for posterity or something.
Our assignment was to design a new type of "scheduling application". The first thing I learned was that Jodi's concept of an "application" is much broader than mine. Most of the examples she showed us were entire products and not just software running on a standard computer. The implicit message was that, to an interaction designer, it is the experience of the user that counts, not the form of the design solution. Jodi placed no constraints on this form; software versus hardware wasn't an issue.
Instead of a fully fleshed-out product specification, Jodi wanted a refined concept for the application that could demonstrate how a user would schedule an appointment, remove an appointment, and handle double-booked appointments using the interface. As part of our familiarization stage, we developed the product taxonomies and mood boards that I mentioned earlier. I found the taxonomies useful insofar as they helped me really focus on how the form of a product impacts the way we use it. They got me thinking about affordances again, which I hadn't really focused on since reading Norman's book so many (four) years ago. I didn't get into the mood boards quite so much, but I did take from them some general thoughts on how human senses and emotions might relate to my interface, as we'll see.
I set aside all this work for a bit when I came up with the initial concept, however. To do that, I reflected on the scenario I articulated in my Visions of a Distributed Future post; I thought of a world, not too far removed from becoming reality, where physical location is less important, we are far more mobile, and where work and play blend together into a single concept of "living". What would a scheduler look like in this world? Despite the advances in mobility, people still can't be in two places at once, so it would have to be heavily time-focused. I threw up some thoughts on my whiteboard:
Around this time I decided to focus on a particular type of user. Since I had no data on what other people want, I focused on creating a scheduling app for people like me; i.e. students / lowly technical staff. I drew a picture of how I conceive of time on a day-to-day, operational basis (its on the left of the whiteboard); essentially, time consists of "now", a past that I care little about since its already over with, and a future that is segmented into slots that I can fill with meetings or other engagements. This concept, combined with the drawing of a fancy armband I doodled next to it, essentially turned into my initial design. It struck me that it resembled a snake, and I started thinking up some ideas for how it might work.
The next morning, I built a low fidelity prototype of the concept so Jodi could critique it:
As you can see, I strapped this monstrosity to my arm and walked around with it for the better part of the day. Strange thing was, this actually really helped me come up with refined ideas for the product; having the snake really sitting there on my arm gave me a new sense of what it might be able to do were it really functional.
For the second iteration, I developed a higher fidelity prototype using modeling clay and a real watch:
The interaction design didn't change much, but this prototype helped communicate the vision for the scheduling application more clearly (I hope). To describe the functionality of the inert prototype, I put together a small product spec sheet and a scenario-based description of how the product handles the functions Jodi asked us to demonstrate. Looking over these might give you a better sense of how the snake works than the photographs alone do.
The knurling and basic product design came largely from my exploration of the taxonomies. The anthropomorphic reactions of the snake came (in part) from reflecting on the concepts that appeared in my mood boards. The general design concept came from the distributed future scenario, although I realized as I was finishing the product that it was really a fairly realistic device even for the near future. It's odd, but I felt that considering an "out there" scenario helped me come up with some interesting ideas even for a product that didn't wind up being as futuristic as I initially thought it would be.
I wish I had the chance to explore more options with this product; once I came up with the general form of the solution I kind of stopped exploring. However, our second project has already begun, and for it we're required to go through a much wider exploration phase. I'm also still a little unsure how much I used the familiarization artifacts (the mood boards and the taxonomies) in my final design. They were helpful, but maybe not helpful enough to justify the large amount of time I spent on them.
If I'd had the time to refine further, I would have liked to produce an even higher fidelity inert prototype (that was thinner, for one, and possibly made of metal rather than modeling clay) as well as an interactive flash movie that demonstrated how the interaction with the snake's screens would work. But all projects have a deadline, and this one's is past.
Dan discusses his design on his weblog if you just can't get enough.
Posted by Geoff on March 13, 2004 at 06:16 PM
This is really cool. I want one.
Email Rob:
Newsable Beta: Getting Close...
announcements, software development
September 22, 2003, 09:53 AM
Apologies for the silence this weekend; I've been working hard on Newsable to complete it in time for a September 30th deadline I agreed on with Jim as well as to get it ready for a project I'm starting with Dana where we're gonna try to build a community around its design and development.
So far I have the entire harvester component ("Cain"; if you author a weblog I read you might have already seen him in your server logs) working, as well as the user registration and story listings. All that's left is site addition and removal, sorting and filtering, and some miscellaneous bug fixes. It's gonna be real soon now, boys and girls...
Here's a teaser screenshot while you wait:
Posted by neema on September 22, 2003 at 07:29 PM
i must say i'm curious to see what kind of interface you come up with. i like the idea of having my blog ship 'default' with the product! lol thanks robin
Email Rob:
Email Rob: