Weekly Thesis Post #19

Early in the morning last Wednesday, I left for the Interaction11 conference in Boulder, CO. I took it as my last mini-vacation before diving deep into thesis through the end of the semester. The keynotes at the conference were excellent, but some of the other sessions were a little more uneven.

Some of my time at the conference was spent volunteering. I recorded 18 bus testimonials of attendees at the conference, and met quite a few of the attendees in the process of doing so.

One opportunity I had at the conference was to practice my thesis pitch. I think the pitch actually went surprisingly well. The element of the project that people seemed to respond the best to is the “social interventions” that it will spur when someone becomes too distracted. I’ve been giving the interventions more thought and emphasis lightly, so I’m glad for that response. Fortunately, I also didn’t hear any negative complaints about the tracking component of the app.

The one downside about the conference is that there wasn’t too much time to actually work on my thesis. So I’m going to get back to that. I’ve got some catching up to do…


Weekly Thesis Post #18

The past week has been very productive. I feel like I’ve progressed a lot in crystallizing my idea and nailing pieces of it down, as well as figuring out what pieces of it need more work.

Sketches

Since last week, I’ve been doing some sketches for what the application might look like and how it would work. Here’s a sampling.

This is a rough application map, which shows the screens the app will need.

Here’s a sketch of what the main window could look like.

Here are a few of the possible views for trends.

And what the mini-window could look like.

And finally, some ideas for interventions when someone gets too distracted.

Wireframes

I took all of the sketches and turned them into a set of wireframes, downloadable in this PDF. Here are a few samples.

This one shows the main window with a visualization of your and your teammates’ distraction levels over the course of the day:

This is the mini-window that will be docked to the edge of the screen:

Here’s what an intervention screen might look like. (The star is a placeholder.)

Unresolved

There are a few items I’m still thinking about…

  • The social aspect. I’ve been thinking a lot about how the system can create interventions to prevent or reduce distraction. I’ve come up with some interesting ideas (in my opinion), including texting a coworker to help you, or requiring you to visit a coworker to unlock your own screen. The idea is that I can use the system to force social interactions and thereby end the temptation of distraction.
  • Visual design. I want the app to look amazing, but there are definitely going to be some time constraints. It’s more important that I get all necessary functionality to influence behavior than it is for the app to look great. So for the most part I intend to use off the shelf UI components unless it becomes necessary not to, or I somehow find some extra time.
  • AV Presentation. I’ll need to create a video to show the app off. I should keep this story in mind as development goes in.

Historygram

I’ve released a few updates to Historygram since last week. Here’s the latest one, version 0.5:

The newest version is available for download. Safari should also automatically detect an update. I redesigned it a bit so that the chart makes a better impression of your surfing habits.

Next Up

I still have more to think about for the social pieces, but I have enough of a direction to get started actually writing the software. I’ve written up an initial schedule that should cover the bulk of the software development. I still need to account for visual design and pieces of the presentation in the schedule once I have a better idea of what the deliverables need to be and in what condition the software will be.

Tomorrow morning, I’m heading to Boulder, CO for Interaction11. I have a great time last year in Savannah, and I’m hoping this year will be just as great. Maybe I’ll even find some people to get some thesis advice and/or hire me!


Weekly Thesis Post #17

I made some good progress this week. I picked a name for the project, released Historygram. I’ve also started working on wireframes, but I won’t be ready to share those until next week.

Historygram

First up, the big milestone this week was the release of Historygram, my extension for visualizing browsing habits.

Technically, it’s still in beta while I gather feedback and fix bugs. But, I don’t expect it will change too much. I hope to release the 1.0 when I have some more time to put together a nice website for it and incorporate some of the feedback I get.

Now, back to the thesis.

Technology Loop

There was a sketch called “Technology Loop” from the TV show Portlandia that provides a funny take on distraction:

Hopefully this project can help break the technology loop?

Review

One thing that I’ve done before starting the wireframing is to remind myself of a few results from research that I think have started to escape my mind as the project has gone on.

What is distraction?
Distraction is something that prevents you from reaching your desired goal.

What kinds of things are distracting?
Potentially, everything. It’s a relative term. Anything that gets in the way of your stated or desired goal is a distraction. Twitter might distract you from your work, or your work might distract you from Twitter. It depends on what you want to do.

When do people get distracted?
Primarily, in three situations: when they are bored, frustrated, or have completed a milestone.

What is underlying the decision to act on a distraction?
I have identified five different qualities of activities that influence the decision: priority, ability, interest, excitement, and pleasure.

How will my project help distraction?
It has three primary features:

  1. It will provide a way to measure distraction so that people can figure out how distracted they are.
  2. It will codify milestones and breaks, so as to try and compartmentalize some distractions into those breaks.
  3. It will add a social element to work so that coworkers can easily share how they’re doing, and by doing so, get help when they feel bored or frustrated and get (semi-)public recognition when they reach milestones.

Name

I think I’ve decided on name for the project: Obtract.

The name comes from the roots of the words “obstruct” and “distract.” Ob-, meaning “against,” and -tract, meaning “drag or draw.” Because in a way, the project should push against the draw of distraction.

Also, it’s short, it sounds kind of like “subtract,” and the .com was free. So there you go.


Weekly Thesis Post #16

We’ve now got less than 100 days to go until final thesis presentations on May 5th. I’ve been spending the week mostly trying to focus and in and decide what it is that I would like have for a finished thesis.

Story

Yesterday in class, we talked a little bit about a story or elevator pitch for our thesis. Here’s mine:

I’m building a service to help knowledge workers reduce digital distraction. The system will watch workers over the course of the workday to provide feedback on how they’re doing, and it will connect with coworkers so that teams can manage distraction together.

One thing I am still missing is a name for the service. I’ll spend some time this week thinking about a a good name.

Requirements

I’ve been working on the project requirements over the past week. Here’s the current version:

User Accounts

  1. A user account is not required to use the application.
  2. A user account is required to network with other users through the application.
  3. Users must be able to create accounts.
  4. User accounts require a username and a password.
  5. User accounts can also include a real name.
  6. Users must be able to request their password to be reset.

Tracking

  1. The app will track a user’s activity over a specified period of time (e.g., one hour)
  2. The app must keep track of the active application.
  3. If the active application is a browser, the app must keep track of the active URL.
  4. Every activity will be marked as distracting or not distracting.
  5. The user must be able to set whether an activity is distracting or not.
  6. The amount of time spent on non-distracting activities compared to distracting activities over the specified period of time will be the distraction level.

Distraction Catalog

  1. The system will periodically collect whether activities are marked as distracting or not.
  2. The collection will be used to determine whether activities are distracting or not by default.
  3. A user marking an activity as distracting or not will take priority over the catalog.

Milestones

  1. Users can enter short descriptions of their progress throughout the day, called milestones.

Social

  1. Users can follow other system users by username.
  2. Users must symmetrically follow each other to share data.
  3. Distraction level will be visible to users who follow each other.
  4. Milestones will be visible to users who follow each other.
  5. The app will provide a way for users to contact each other through other applications or media.

Breaks

  1. Users can take breaks over the course of the day.
  2. The app will not track activity during breaks.
  3. Breaks will be limited in frequency and duration.

Mini-Visualization

  1. A mini-visualization will be available that shows the distraction level over the specified period of time.
  2. The mini-visualization will appear every time the user switches activities.
  3. The mini-visualization will show whether the current activity is distracting or not.
  4. The mini-visualization will stay visible if the activity is distracting.
  5. The mini-visualization will hide if the activity is not distracting.
  6. If the user switches to a distracting activity, the mini-visualization will provide an option to return to the most recent non-distracting activity.

Main Window

  1. The app will have a main window.
  2. The main window will allow users to log in to their accounts.
  3. The main window will allow users to follow each other.
  4. Users will be able to enter milestones from the main window.

Distraction Level Visualization

  1. The main window will show a visualization of the user’s distraction level over the past day.
  2. The visualization will include the distraction level of followed users.
  3. Milestones (including those from followed users’) will be visible on the visualization.

Activity Visualization

  1. The main will include a visualization that compares the distracting and non-distracting activities the user participates in over the day.

Intervention

  1. When the distraction level falls below a certain threshold, the app will prevent access to distracting applications.
  2. Users must be able to bypass the intervention.

Requirements and You

I was asked by my thesis class instructor/advisor Paul Pangaro to put together a brief presentation about requirements. Here’s a PDF of it.

Historygram

I spent a lot of time over the past week resuming work on Fidget, my history analysis extension for Safari. I’ve renamed it to “Historygram” to make it a little more clear what it does. I’ve only got a few more bugs to fix. Hopefully I’ll be able to release it this week!


Weekly Thesis Post #15

Almost one month later, it’s back to work. I’ve most of the last month doing some more research. I reviewed my own research, read more academic research, and read (even more) books. I was pleased to find research that confirms some of my own findings, as well as some new insights.

Research Highlights

Here are some of the high level highlights from some of the papers that I’ve read:

  • People are interrupted every 6 to 12 minutes.
  • 50% of interruptions are internal (i.e., self-interruption) and the other 50% are external (i.e., caused by other people)
  • I learned about “chunking behaviors,” where a user waits until task completion to switch to something else. I had previously described this as “milestones.”
  • One of the best ways to determine mental workload is pupillary response. And interruptions are less disruptive if they are timed to the “valleys” in that mental workload.
  • After being interrupted, most users do not resume the task they were originally working on.
  • More interruptions result in faster, lower quality decisions.

I can apply some of these findings to my project. For instance, I shoulder consider external interruptions more carefully, and I should make a better point of encouraging users to resume the work they had stopped.

Winter Reading

In keeping with my “Summer Reading” list from last semester, here’s what I read over winter break, in no particular order or grouping:

  • The Art of Interactive Design by Chris Crawford (previously started)
  • About Face 3 by Alan Cooper (previously started)
  • Glut by Alex Wright
  • The Craftsman by Richard Sennett
  • The Emperor of All Maladies by Siddhartha Mukherjee
  • Where Good Ideas Come From by Steven Johnson
  • What Technology Wants by Kevin Kelly
  • Cognitive Surplus by Clay Shirky
  • An Attempt at Exhausting a Place in Paris by Georges Perec

Next up, I’m going to read Rework by Jason Fried and Making Ideas Happen by Scott Belsky.

Punchline

I also stumbled on a paper that describes that shows if you’re angry, you’ll only get angrier if you take out your aggression in a physical way. Ironically, one of the best ways to vent your aggression is… distraction. So, instead of pretending to punch your friend in the face (via pillow and/or punching bag), you should check out Justin Bieber’s latest haircut instead.


Weekly Thesis Post #14

We’ve reached the end of the semester, so this will be the last thesis post of the semester. I expect I’ll continue blogging about it next semester.

Process

This past week has largely been a production week, for thesis as well as the other three projects I had due last week. For thesis, I had the storyboards and prototype ready last week, so this week has largely been about refining the storyboard and building a presentation around it, though I did make a few changes from my storyboards last week.

For one, I cut out the idea of analytics living on a web site somewhere. I think there’s a compelling case to be made for a broader sense of analytics of what everyone is doing at work, but the core of this project is behavior change to prevent distraction in individuals. I’ll be open to revisiting the idea if it can inform a way of influencing that individual behavior. The impact of this decision is that more of the analysis has to live in the app rather than the web site, which I think will be better for the user experience.

I also pulled out the idea of badges. I think they’re kind of fun, but possibly a distraction from what the core of the idea is all about. I want to prototype to see if badges are effective, and I’ll make the decision based on that.

Presentation

I gave my presentation yesterday. I’ve posted a few of the documents from my final presentation.

I got some good feedback from the presentation. Some of the interesting comments were:

  • Do a better job of emphasizing the positive feelings that people have when they complete their work.
  • Do a closer analysis of the social relationships at work. Is it fair to distract the people who are concentrating with coworkers who are distracted, or would that make the situation worse?
  • Think of ways to allow people to self-report.
  • Allow for different styles of working.
  • Consider adding a way of tracking and finishing goals. Maybe even allow them to set out milestones ahead of time to help them reach those milestones.

Also during the feedback section, one commenter suggested that one of the design principles of this project is that the application cannot be distracting. I do not agree with that principle. My stance is that, since distraction is always relative to something else, the application will inevitably be distracting. The challenge is to make sure that it’s distracting in the right way, to improve behavior.

One comment that also comes up at most presentations is that I should try to drive people to the place where they’re most concentrated or meditative. I think it’s a compelling idea, but it would require a different approach from this project. This project is about quieting the things that prevent you from doing your work generally, whereas the other project is about improving the experience of working on a single task. I can’t redesign every software application to make the experience better (much like OmmWriter tries to do), but I can design a broader system that fills in those gaps users figure out how they’re using those apps and how they’re doing.

Upcoming

I plan to do some more work over winter break. I still have a pile of articles I intend to finish. I also want to finish up the Fidget browser extension I started working on the middle of the semester. And finally, if time permits, I hope to start building and prototyping the application in more depth.

See you next semester!


Weekly Thesis Post #13

I’ve spent the last week preparing for my final Thesis presentation of the semester. It’s taking place next week, and I’ll be going first. So far, I’ve been working on the storyboard and the prototype.

Storyboard

Here are the sketches I’ve got for the storyboard so far. It follows the story of Joe as he uses the distraction app to guide him throughout his day at work. It covers the distraction meter monitoring his tasks and adjusting, and it also shows it locking out specific applications. It also demonstrates milestones and breaks, showing elements of a social network for your team of coworkers.

I showed the storyboards to my advisor, Paul, and he gave me a few pieces of advice:

  • Think about the visualization of the day at work more carefully. Generally, up and to the right “seems” good and down and to the left seems bad.
  • A number is a little bit opaque as a means of communicating a distraction level. Consider a meter or some other visualization instead.

Prototype

I’ve also been working on a prototype that I can demo. Here’s a video of it in action.

Distractometer Screencast from Eric St. Onge on Vimeo.


Weekly Thesis Post #12

Over the past week, I’ve continued to sketch more thesis concepts, including some combinations of the best pieces of my previous three concepts. I’m working up to the final presentation of the semester on the 20th and 21st. I don’t have anything very interesting to report about that quite yet, but I’ll have some more about it for next week’s post.

In the meantime, we’ve been asked to write about a special topic this week: viability.

There a few distinct areas of viability that I’ve been thinking about for my project: viability of concept, viability of project, and viability of business.

Viability of Concept

This is the most important kind of viability of my project. This should be both confirmation that the problem that I have defined is actually a problem, and that my strategy for solving that problem is effective. Or, to put it another way, am I solving the problem as I have stated it?

So far, I think that this is an area of the project that I need to figure out. I need to do more prototyping based on my final concept proposal to figure out the details of my strategy. But, I think I’m on track and I think I can viably show clear thinking and analysis of the problem.

Viability of Project

I see this as the execution and implementation of the concept. On the technical side, I’ve been careful to propose things (publicly) that I have a good sense I would be able to produce in the amount of time we’ve got. I’m not too worried about this aspect of the project.

On the visual design side, I think there will be some opportunities to show my visual design skills. Or a good opportunity to show that I can hire someone and guide them to a great visual design. (But I’m hoping for the former!)

Viability of Business

I am not doing this project with the explicit goal of turning it into a profitable business, so I am probably not giving this as much thought as I could. But, profitability certainly would be nice.

Throughout the process, I’ve been taking note of the different business models of the apps I’ve seen out there, including free, open source, shareware, and subscription models, as well as the relatively rare advertising-supported apps. I’m going to be watching carefully as the new Mac App Store comes out within the next few weeks to see the effects it has on Mac software sales. The difficulty is that I see this project as including both a front-end product and a back-end service, so the business side of it needs to account for the ongoing costs associated with it. Sponsorship might also be an interested idea to pursue.

Ultimately, at the end, the most important thing for me is that I have a good execution of a good idea.


Apps: Think

Think is an application by Freeverse that helps you to concentrate on a single application.

On the surface, it works like some of the apps I’ve reviewed here before, particularly Backdrop and Isolator, where it darkens the screen behind the frontmost application.

Think goes one step beyond the other apps: It adds a built in task-switcher, which includes the running applications in your Dock.

When you pick an app from the task switcher, it brings that app to the front. But when you try to click onto another application, it brings your app back to the front. You can still use the dock and cmd-tab switcher to switch between applications, though. It acts as a small but effective way of routing you through specific ways of switching applications. I actually wish it was more strict in keeping you on task. I think it would work more smoothly if you had to go through Think to switch to anything else.

It’s free download. Give it a try!


Apps: Anti-Social

Anti-Social is a utility that blocks the “social parts of the internet.” Functionally, it’s just about identical to Freedom (and shares the same developer). The difference is that Freedom blocks everything and Anti-Social just blocks the social stuff.

Also like Freedom, you get five free uses of Anti-Social, and then it’s $15 for the paid version.