Mark Wilhelm

INFO 608, Winter 2008

March 20, 2008

Final Reflection Paper

Introduction

The description of this assignment posed a few questions for reflection, and so I take some time in this paper to give some (hopefully) thoughtful answers to them. In doing so I’ll try to cover how well our class designs met the stated goals of the course from the course overview; also I consider our software in light of the text’s proposed heuristics for online communities. Finally, I conclude with a consideration of where we are in the history of social interaction software with respect to the places Douglas Engelbart and Vannevar Bush hold in the history of technological innovation.

Did the course meet/not meet expectations and needs?

When I came into this course I was expecting to learn a kind of aesthetics of interfaces. I expected to encounter a delineation of what makes a good interface and what makes a bad one. And I did learn this. But the additional thing that I learned that I was not expecting had to do with the process of constructing an interface. The questions and criticisms that our team received during the iterative process of constructing our proposed software for the IPL were invaluable learning tools. What these class sessions taught me was how the process honed the interface and worked out the kinks in the initial design.

The big lesson I learned from this process is how difficult it is to clearly delineate a scenario for a user to perform on an interface. We initially started with what we thought was a simple scenario of adding a book or URL to a group "bookshelf". After hearing that this was perhaps not enough of a scenario, or that there was not enough context in terms of users sharing these resources, we went in the opposite direction and added perhaps too much context on the interface. Our intent was to place the scenario in the context of other group resources such as chat. However, the classroom discussion revealed that these other resources distracted from our primary scenario. Our evaluators spent time figuring out how the additional resources worked and focused on those rather than on our primary scenario of adding books to a shelf.

In our final design we have attempted to hone the user’s focus in on the primary scenario, while also leaving it in the context of other group functionality that would be available if our conceptual design were fully fleshed out.

How was the format of the course successful in providing you with a good learning experience about interaction design? What would you suggest could be changed?

In general the format of the course was successful. There were several things that I liked about this course. As mentioned previously, I especially like the heuristic and walkthrough group feedback sessions of our social interaction prototypes. These were especially helpful in fleshing out problems with our interface.

In addition to these, the VMT software provided an interesting perspective on social interfaces. Especially interesting was the “deitic” referencing functionality in the chat portion that allowed us to point out parts of drawings we were discussing and which chunk of conversation we were referencing. The textbook provided sound information, most especially in delineating principles of heuristics, walkthroughs, and interface evaluation. The readings were interesting, especially the Scardamalia and Bereiter reading on knowledge construction and also the readings on Vannevar Bush. Group discussions in class were often lively and illuminating. I found the thread of “Google vs. classification systems” and “search vs. browse” especially interesting as a library science student.

If I could suggest one change to the format, it would be to formalize a requirement that in addition to listing problems with the web sites, members of other teams also list concrete ways that the site could be improved. Our team picked up several suggestions from the class discussions that were helpful in this regard, so it would be nice to make it a format requirement so that all teams could be sure to benefit from it.

If you had another 10 weeks to work with your teammates on the group project, how would you proceed?

Since Team 5 implemented a “group bookshelf” concept, I would use this time to think about adding some functionality to delineate what happens after the user adds a resource to the shelf. A lot of our scenario was taken up with the mechanics of actually adding something to the bookshelf. However the possibilities for social interaction really begin once an item is added to the shelf. We touched on one scenario – recommending a book to a friend—but there are many other possibilities. For example, a user can rate a book with a star rating and share this rating. A user can tag the book and all of the tags from all users can be viewed in a tag cloud. Users can also comment on the book and share their comments.

Indeed, there is quite a universe of functionality that could be added to our initial design. In addition to the “canned” functionality like star ratings listed above, much of which has been tried and tested on existing web sites, we could perhaps think about how software to implement knowledge building might be added to the IPL, and what form it might take. This would be a challenging task, but if we followed the Scardamalia and Bereiter article’s example of using scholarly publishing as a model, we might be able to create something concrete in 10 weeks.

What do you think should be adopted by the IPL?

This difficult question might best be answered if we looked at the software proposals from a few perspectives that we did not use in the class evaluations.

The first perspective has to do with the 4 focus issues for the term which appear on the course overview document. These issues were social computing, collaborative learning, knowledge construction, and community building. One way to decide which design should be adopted by the IPL would to discern how well the designs measure up against these 4 goals.

Social computing is framed in the overview as “how can you design software to support interaction among people in a community?” Considering the support of social interaction as a goal, all three designs were able to meet it. Team 1 allowed users to interact by recommending books as well as sharing comments and star ratings with others. Team 3 supported social interaction via discussion boards, chats, and the ability to see what users shared common interests. Team Five’s design supported the concept of groups, in which group members could share a bookshelf and comment on the books and resources placed on it.

Moving on to the goal of community building, which was defined as “how can you design software to increase the sense of community among users?”, it would not be a stretch to say that all three designs met this goal. The interactions itemized above supported by the respective designs all foster the building of communities, whether it be people on a discussion board or group members sharing a bookshelf.

The other two goals, supporting collaborative learning and knowledge building, were perhaps more difficult to meet. Collaborative learning is defined as “how can you design software to support learning in and by groups?” Knowledge building was framed as “how can you design software to help groups of people access relevant information resources and build shared knowledge?”

Knowledge building is a complex undertaking and takes a great deal of study to support. These designs hold promise for meeting these goals “down the road,” but right now within the limited timeframe of the class it was difficult to mock something up that could meet these challenging goals.

Another perspective from which to evaluate the designs is to consider them in the light of one of the several sets of heuristics in the text. One set of these is the “heuristics for web-based online communities” proposed in the text (p. 695). Split between the two perspectives of usability and sociability, these heuristics are listed below, along with a few comments on how the teams met or failed to meet the goal.

  1. Sociability: why should I join this community?
  2. Usability: how do I join or leave this community
  3. Sociability: what are the rules
  4. Usability: how do I get, read, send messages?
  5. Usability: can I do what I want easily?
  6. Sociability: is the community safe
  7. Sociability: can I express my self as I wish?
  8. Sociability: do people reciprocate?
  9. Sociability: why should I come back?

Numbers 2, 6, and 7 were not really addressed as they were to a degree outside the limited scope of the design and the time available. 6 and 7, however are particularly important to a site where children may socially interact, and a fuller implementation of the designs would have to consider them. Perhaps the one of these that we focused on most in class was number 5. Number 4 was only covered by team 3.

For number 9 (“why should I come back?”), I am sure all three teams hope that the usefulness and usability of the functionality itself provides a reason for wanting to come back.

There is another set of heuristics that can be used as a perspective for viewing the design proposals from the class. These are the six heuristics specifically for web interfaces listed in the text (adapted from Nielsen and others, p. 692). They are listed below accompanied by a brief note about how well the teams met them:

Avoid orphan pages (dead ends, pages that are not connected to the homepage)

Some of the initial designs for the teams may have had this but by final designs all teams had resolved this issue.

Avoid long pages with excessive white space that force scrolling

This was not a problem for any of the teams.

Provide navigation support, such as a strong site map that is always present

All of the teams provided this support; Team 3 with tabs, Team 5 with a “breadcrumb” trail, and Team 1 via a sidebar menu.

Avoid narrow, deep hierarchical menus that force users to burrow deep into the menu structure

This was not a problem with any of the team’s designs.

Avoid non standard link colors

Some of the teams, including my own Team 5, made the mistake of using non-standard link colors (sometimes without underlining) early on; however by the last class session all instances of this problem had been corrected.

Provide consistent look and feel for navigation and information design

All of the teams did very well on this.

Finally, there were several guidelines for evaluating functionality changes to the IPL that were outside the scope of this class but are nonetheless important. One of these might be called a “political” heuristic. For example, Dr Abels noted that the links for a book should direct to where you can find it in a local library, not a bookstore where you can purchase it; also they would not have the full text because the IPL appears to be there to complement local libraries, not compete with them. So when we considered the bookshelf functionality we were not aware of these considerations.

So, we can see that there a number of different guidelines by which to measure the success of a design, including those listed above as well as the ones we used in class. However, now we must move beyond measuring against guidelines and conclude this section with an the answer to the question of what the IPL should adopt! I believe all of the designs are very good. And I think if I had to pick one if would be Team 3’s design, because of all three I think that the concept of searching across discussion boards, chats, etc. is a very innovative idea. However if I made a recommendation to the IPL I would propose a hybrid of Team 3’s design with either Team 1 or my own Team 5’s design. I think that adding the concept of a bookshelf as embodied by the Team 1 or Team 5 designs would make a better piece of software.

Conclusion

It would be appropriate to conclude this reflection by contemplating where we are in the history of social interaction software. Are we at a similar place to where Vannevar Bush was with his Memex? A place where the software we currently have is only an anticipation what is to come? Are we seeing things only incompletely now as he did? Has the groundwork been laid for something much more spectacular than we are currently seeing? Or are we further along than that, with useful software in place and having a positive effect on society?

Kim, in his “Manifesto for Collaborative Tools,” would answer that there is much work to be done to make collaborative software useful. Citing problems in such fundamental areas as sharing documents, he states that the we are not where we should be and proposes some suggestions. Some of these include a collaborative framework built around the concept of standardizing Engelbart’s idea of backlinks.

Answering from our own narrower perspective of the Internet Public Library site, most of the class would agree that there is much work to done in order to make the IPL a useful interaction and collaborative tool. As noted in class, the only piece of social interaction software on the site is the “Ask A Question” service. But as our class designs have hopefully illuminated, there is much that can be done on the IPL even using existing social interaction software, let alone what software the future may bring.

For it is the future we must think about. One of Douglas Engelbart’s tenets is that we must improve technology in order to help solve some of the great problems facing humanity. And aside from the scientific and technical strides that could be made if the right technology were in place, using social interaction software to connect people certainly would help further humanity along.