Holly Habstritt: workspace

May 10th 2012

Wander Sign In / Up Flow Challenge

While in NYC, I’m taking the chance to work with a couple of startups in the Techstars program. One of these companies is Wander.

Wander won’t be launched for a few more weeks, but until then, you can check out the Wander blog and start participating in Wander Weeks while anticipating the beta launch.

When initially approaching the sign in and sign up flows I thought it would be similar to sign up flows I’ve approached before. However, there was a key element to their pre-beta sign-up that made a unique solution necessary.

For the past few months, you could sign up to be notified when Wander launches, but also reserve your Wander name. In this process only a username and email were captured, but no password. This is great for lowering the conversion barrier and having a friendly way to capture user emails, but produces another use case to account for when launching.

The effect of this key anomaly is that at the time Wander Weeks is released (and any time thereafter) we could have 3 types of users:

We needed a way for all 3 user types (when I say “user types” here I am only referring where they are in authentication and not personas) to enter Wander, and handle the odd case of the user who has entered their email, but not yet provided a password. The one variable that all users need to or have already entered is their email. So, the solution is to first have the user enter their email. This essentially acts as a key to tell us which door to open next. Once we determine if the email is known or unknown to us, we then know how much information we already have from the user, and therefore know which fields to populate next. (enter password you have already defined, or enter a new password for the first time). Another benefit to this flow is that we do not have to bring the user out of the experience and to their email to confirm, resulting in a lower drop-off rate. For the few to none cases where users attempt to enter another user’s email before they have defined a password (see 50% user type), we allow the user to reset their password and confirm any changed passwords via email or contact us directly to monitor what happened.

Stay tuned for the full Wander release. It’s an exceptional team and I’ve had a lot of fun working with them.

Posted at 10:48am.

April 18th 2012

|#

I sent out a quick survey to get a general idea of how people both use and feel about notifications. This includes methods from mobile push notifications to Growl style desktop notifications, notifications triggered by content, and perhaps system notifications as well. Knowing separately how developers implement and end users consume notifications is also important, but we can consider how to gather user-type specific patterns in another survey, personal interviews, or by observing use.

42 people responded to the survey and a majority also left additional thoughts at the end of the form. I was pleasantly surprised at the effort put into the additional thoughts as it allowed this general form to give us even more information than intended.

Here are some points you might find useful, but click through the images to see for yourself:

Receiving a notification for interactions with personal accounts or the user’s own content was most favorable. 78.6% of survey takers like notification for replies, comments, or shares from sites like Twitter, Facebook, Tumblr and 57.1% for Twitter follows or Facebook friend requests. Calendar events were also noted several times in the “other” field. (see image)

Most users want to be notified immediately when content becomes available. (see image) However, some noted that while they would like immediate notification for direct and personal communication, for non-personal or non-time sensitive notifications they would prefer it to be occasional.

50% of people want notifications on both mobile and desktop. A combined 40% noted a preference for either desktop or mobile. This is an incentive to focus on improvements for multi-device/platform notifications.

The many thoughts provided in the open field at the end of the survey were especially helpful. I could post 20+ but here are a few from recipients, content creators, and developers:
“As little battery drain as possible on mobile devices. “

“When pushing notifications to multiple devices, it bugs me when clearing the notification on one doesn’t cross all devices.”

“This would be really useful for development-related things where I want to be notified while I’m around doing development because it helps the team keep in sync. Currently we use IRC for this, but IRC clients aren’t very useful on mobile devices and it might be nice to keep in sync without having to be on IRC where I’m pesterable.”

“Like most people I am addicted to them so its a love hate relationship. Would be nice to be able to very easily turn them off if I wanted to escape for a while”

“They should be contextual to time/location. Or, in other words, adherent to which ‘mode’ I’m in: working, relaxing, hanging with friends, etc.”

“I love them because, they keep me on track of my activity being it personal or professional.”

“As an author of several web services, it would be nice to have a better format than email for sending such things.”

In general, it seems as though notifications discussions trigger a very personal response. Not surprising, transparent intentions from content sources, ability to manage output, and the need to be in control, is the overall tone of the feedback. Users love notifications when appropriate, helpful, and not intrusive of personal time and space.

Thanks so much to those who took the time to complete the survey and write an additional response about their personal uses and ideas to make being notified a better experience. We really appreciate it!

The survey is still up. Take it yourself, here.

Firefox Notifications is a project I have been working on with @jeffbalough at Mozilla.

Posted at 2:46pm.

April 3rd 2012

Notification add-on update

|#

While I don’t consider myself a visual designer, I felt that mocking up something more visual than wireframes would help to get feedback from a wider audience. For our prototype we will stick to a very minimal visual design.

The first mock-up is quite minimal and text-focused.

The second mock-up both uses the dominant color in the favicon/source icon to better visually differentiate the source content. It also shows how we could use content from sources like LastFM and Linked in and potentially use the visual assets offered for different post types. You can see a music event recommendation, message from a LastFM friend, or notice from a LinkedIn group.

As I mentioned, the colors used in the second version are taken from the dominant color of the favicon (or if we have a default icon for common social sites). Chrome does this in their home tab. Etsy and Dribbble also use this method for searching by color. Example: http://lokeshdhakar.com/

We have also set a few requirements to keep the prototype simple as we test with a few content source types. As we gauge the volume of content displayed and expectations for viewing this content, we may need to revisit these rules once again.

Our take on the prototype is that this is timely content. This is not a service like Delicious or Evernote where you keep links that you want to revisit. If we offer an archive, this becomes a different kind of tool than intended. For now, we have set the following to keep the “what you see and when” logic simple:

1. Items shown are from within the past 24 hours.

2. Maximum height of panel extends to height of browser. (not demonstrated in visual design) After which, a scroll bar is displayed. Edgecase: If the user has (i.e.) 50 items to be shown from 10 sources, we should consider a rule to show x items from each source with a “x more” indicator to expand all. It is important that the user can see as many sources as possible and the most recent items from these sources. The user shouldn’t have to scroll excessively to see hidden sources in the bottom of the panel.

2. Delete item from view when it is ‘read’. ‘Read’ is defined by the user clicking on link/button within item.

3. User explicitly deletes single item from view by clicking the ‘X’ icon. (“Are you sure?” verification not needed for single item)

4. User explicitly deletes all items from a source by clicking the ‘X’ icon. (“Are you sure? This will delete all items from this source” verification needed)

5. If an item has not been seen since panel was last expanded, it can have a 5% opacity background of the dominant hue. (as shown in attached screenshot of more colorful mock-up)

Posted at 4:12pm.

March 19th 2012

1 note |#

I’ve been working with Jeff Balogh at Mozilla (@jeffbalogh) to consider the best way to approach push notifications for Firefox. We first explored how it could work with current desktop notification styles in Windows and Linux, as well as the new Mountain Lion notifications set to come out soon. We also considered how it could work as an Apple menubar extra and integrate with other operating systems, be displayed in the Firefox home tab, and use current mobile notification systems on iPhone and Andriod. You can see our first discussion sketches and notes here. (Add-ons documentation PDF, here)

In many cases you shouldn’t notice the browser. Once you do, it’s usually because it’s slow or gives you an “oh snap…” or some annoyance. The only time a browser is valuable to most users is when it’s silent and obedient. I’m curious how to add more value to the browser again. It doesn’t need to be a destination, but perhaps a mediator between content source, desktop, and user.

Jeff wrote about Firefox notifications earlier this year in his blog: Introducing Push Notifications

ArsTechnica also wrote a follow-up article: Mozilla developing Web push notification system for Firefox

We’ve decided to first start with a Firefox add-on in order to test interaction, usability, and integration of various content types. The screenshots to the right are selections from the wireframes. Take a look for a preview of what we’ve been working on.

• View the full PDF here and please send any feedback to [ holly.habstritt at gmail.com ] or @habber.

Next steps are to work on visual design and do some testing - both on the technical side and to see how users react to what we have done. I am also interested in user behavior for notifications in general.

Below are some blog posts and resources focused on notifications if you’d like to read more. I think it’s one of the most important and interesting topics to address this year for browsers, desktop, and mobile.

Cocoa IA Blog: Getting Notified

Fred Wilson’s post on Mobile Notifications

Airgram API

Urban Airship

iPhone notifications UI

Mountain Lion Notification Center preview

Enable Desktop Notifactions for Gmail in Chrome

W3C Notifications

Posted at 10:33am.

March 17th 2012

|#

I thought I’d share a product release google doc that I created to track releases, tasks, and what we’ve learned about our product and team as we go from release to release.

Not every product needs 40 pages of documentation in a ms word file that nobody wants to read. I’ve taken a typical PRD (product requirements document) and a great simplified method by Adam Bullied [ which you can check out here ] and made a spreadsheet that you can collaborate on. Each release has a tab and there are also tabs for release history, upcoming, and goals you’d like to achieve. You can make this spreadsheet as simple or extensive as you wish. Just duplicate the file and delete what isn’t right for you and your team.

I like breaking up each release into the following, which you can see defined in Adam’s post: theme, requirements, criteria, goals. I like splitting the requirements area into ‘Main Driver’, ‘Constraints’, and ‘Floats’. This works best once you’ve gone into development and quick release cycles. You can see in the template how I left one example partially filled in. In this example I’ve tried to incorporate UX and visual design. It’s going ok, but I’d like to modify it to focus on specific deliverables next time when in a more design heavy part of the release.

This definitely isn’t for everyone… but for those who like collaborative spreadsheets and hate 40 pages of words as your product management method, this might be something to try.

• My Product Release Planner (google doc) (check it out and give me feedback)

Another tool I really like is Team Gantt. Gantt is a word a lot of people don’t want to hear, but I love the minimalism and interaction of this app. A tool is only worthwhile if it’s used effectively and for the right purpose. I’ve noticed on small projects visual designers and/or those without project managers enjoy Team Gantt.

Posted at 11:40am.

I thought I’d share a product release google doc that I created to track releases, tasks, and what we’ve learned about our product and team as we go from release to release.
Not every product needs 40 pages of documentation in a ms word file that nobody wants to read. I’ve taken a typical PRD (product requirements document) and a great simplified method by Adam Bullied [ which you can check out here ] and made a spreadsheet that you can collaborate on. Each release has a tab and there are also tabs for release history, upcoming, and goals you’d like to achieve. You can make this spreadsheet as simple or extensive as you wish. Just duplicate the file and delete what isn’t right for you and your team.
I like breaking up each release into the following, which you can see defined in Adam’s post: theme, requirements, criteria, goals. I like splitting the requirements area into ‘Main Driver’, ‘Constraints’, and ‘Floats’. This works best once you’ve gone into development and quick release cycles. You can see in the template how I left one example partially filled in. In this example I’ve tried to incorporate UX and visual design. It’s going ok, but I’d like to modify it to focus on specific deliverables next time when in a more design heavy part of the release.
This definitely isn’t for everyone… but for those who like collaborative spreadsheets and hate 40 pages of words as your product management method, this might be something to try.
• My Product Release Planner (google doc) (check it out and give me feedback)

Another tool I really like is Team Gantt. Gantt is a word a lot of people don’t want to hear, but I love the minimalism and interaction of this app. A tool is only worthwhile if it’s used effectively and for the right purpose. I’ve noticed on small projects visual designers and/or those without project managers enjoy Team Gantt.

March 1st 2012

|#

Last year I worked on an image recognition and augmented reality app called Stiktu. This started as an R&D initiative from the wonderful people at Layar. It’s not yet available in the US, but after some additional use and testing in Europe, it should be available in more places soon.

Specifically there are 2 things that have been exciting to see evolve. One is the image recognition technology itself. What could barely be rendered on a still, planar surface, can now be displayed on a book, building, poster, t-shirt, at many angles and ranges of motion. The second is how creative the community has been that has taken to the app. It’s honestly more fun to play with than I thought it would be. I initially was just interested in the technology and not so much the social aspect, but now that it’s being used, I can’t wait to get it into as many hands as we can!

The pictures on the right show a little hack day at my house in the first month of Stiktu (then called “Rachel), a few examples of Stiktu creations, and various flow and wireframe samples.

Posted at 10:57am.

|#

A few weeks ago a couple other creative ladies (1 interaction designer & 1 visual designer) and I were feeling the need to do something creative, but also tangible, outside of our usual work. I’ve wanted to do more of the following lately: 1) sewing, 2) music, and 3) programming. It seemed like checking out Lilypad would be a fun challenge and hit all the birds with one project. Lilypad is basically Arduino, but instead of soldering, you sew the connections with conductive thread.

If you want to order Lilypad (and other fun electronics stuff) in the Netherlands, Pieter Floris is your man:

In the US, check out SparkFun.

We noticed that SparkFun organized starter kits in a friendly way which was nice since getting into this can be a little intimidating. However, Pieter was great and exchanged a few emails with us to make sure we ordered the right stuff to get going. He even threw in some freebies.

The best place to start is going through the tutorials that Leah Buechley put together - MIT site.

We’ve also discovered an awesome community and (free to download) tool at Fritzing.org. The picture on the right shows a screenshot of the abstract view of the prototyping tool. (download it here) Another view is basically like Omnigraffle, but with specific arduino and lilypad stencils, so you can draw your flow before getting hands-on. You can see Klasien’s lovely pre-sketch as well.

So we’ve all had a lot of (sometimes frustrating) fun figuring out the basics, but now it’s time to make something real. You can see the start to my pattern making, which I’ll start sewing next. I’m making a daylight alarm clock, which is technically pretty easy. How does it fulfill my 3 reasons for trying out Lilypad in the first place?

1) sewing: well, I get to sew an object of some sort to attach the Lilypad too, of which also requires stitching together the connections.

2) music: I’ll program a little song to play from the buzzer once a set light variable is met.

3) programming: I need to write the code that makes this all work… it’s a bit new to me and I have mostly some syntax issues, but initially it was super easy to get sensors working and output. The challenge is making one respond from the other and also start adding controllers like sliders and potentiometers.

So, next time I post, I’ll have something worth looking at. For the next few craft nights, less wine and girl talk, more making stuff.

Posted at 12:00am.

February 15th 2012

|#

Hey, it was Valentine’s Day! This is what I made for @robertgaal.

It didn’t turn out as good as the example, but still better than I expected! Try one for your sweetheart: blog post and template for pixel pop-up valentine.

Posted at 12:00am.

February 4th 2012

|#

-18C doesn’t usually phase my northern Minnesota blood, but I’m a little out of practice. We got hit with a little blizzard here, but it’s a chance to break out the Sorels and bike on.

Posted at 11:49am.

December 26th 2011

new release: step 1

|#

First step to getting my brain around possibilities for next product release.

Next up is making wireframe and flow proposals to go through with the team. From these proposals, as a team, we will figure out what is feasible. We also weigh the value of things we want in the release with tasks we may just now realize need to be done before tackling items in this release proposal. These can be anything from performance issues, resulting by inviting more users and adding features, to needing to hire another programmer or visual designer to get the proposed items done in our goal time.

release sketch from user perspective

Posted at 8:30am and tagged with: one column,.