How Do We Harness Our Idle Mobile Consumption?

I’ve got this nagging thought. More of a question really. The kind of thing that keeps you up at night.

Let’s rewind a couple weeks, just before I uninstalled FB from my phone. I started noticing my typical usage pattern of the app – I found myself skimming content, finding nothing of interest, refreshing, not seeing anything new, refreshing again. How often did I do it? I didn’t keep a count or anything, I just kind of became aware of it, like the lights coming up slowly in a theater. But it was a lot. So much so that after I uninstalled the app, I found myself pulling out my phone instinctively, unlocking it, and wondering what I was doing and why. (Spoiler alert: after uninstalling the FB app, my phone spends about 50% less time in my hand. Try it for a week.)

I keep coming back, though, to the usage pattern – skim, refresh, nothing, refresh. Looking back, I did that a lot. Paying closer attention to how I use Twitter, I do it some, but less than I did on FB.

What am I looking for?

Ultimately, I don’t think I’m looking for anything. I think I’ve got a few seconds – not much more than that – and I want to fill it with something. That something, in this case, was scratching at the itch of data addiction. For some people it’s taking a turn in a casual game. What I’m not able to dig into effectively is how much idle time we collectively spend there. It’s not the same data set as the mobile casual games market, but there’s some overlap there. In lieu of actual research papers in the area (but do share those if you have them) – how many of you find yourself holding your phone in your hand, looking for something to do with it? How often?

So I see these few wasted seconds, and I multiply them by N, and it looks like a big pile of wasted seconds, and I wonder how we can put that time to better use. Projects like Galaxy Zoo did a great job of this for the desktop, and they have built a number of projects around crowdsourcing data sorting that look great – and maybe that’s what I’m after.

Maybe.

What I really want to do is harness that time for open source projects. I just can’t work out how. Mobile is a poor form factor for writing code or documentation. Anything text intensive falls outside the parameters of spending a few idle seconds on something. But I’m not ready to take “It’s not possible” for an answer.

Looking at what the mobile form factor is good for, I want something I can do with my thumb. A few use cases spring to mind.

Triage Bugs – A bug has been filed. I see the text of the bug and get asked a Yes or No question that helps to move it along the pipe. An example might be as simple as “Is this a bug?” – it may be chaff or spam or a test message. Other examples might be “Do we need to ask for a screenshot?”, “Is the version info included?”, “Is this correctly categorized?” Every Yes answer helps move the bug along, every No answer could prompt the filer for more info, or allow the user to take a subsequent action (Add a quick note, categorize, etc).

Pull Request Micro-review – Doing a full review on a pull request on a phone sounds painful. Is there a way to ask simple questions of a pull request that would be useful? “Does this conform to style guidelines?”, “Are there tests included?”, “Is the code well documented?”, or maybe even “Do you like this Pull Request?”

Stack Ranking – Given a pair of bugs or features, which one do you think is the higher priority?

Rendering Validation – This is very niche, but if the project performed some form of graphics manipulation, this would be a great space to feed in test data (images) and validate that the output matched expectations.

Any and all of these have potential downsides, but rather than looking at why they would never work, I’d love to hear what could make them useful. Or what else might be useful. Or any thoughts about what people have tried that worked and didn’t work. Or really just anything.

Any thoughts?

So. Where Has He Been?

Obviously, things went a little stale.

I’ll try to explain.

Just about the time I got rolling over here, I experienced what could only be described as an upheaval in my personal life. One aspect of the upheaval was a relocation on the other side of the country to see my father for what would be the last four months of his life.

Moving that far from what had become my home meant I had to do something to keep in touch with my friends. Something meant Facebook. I’d never been a big user of it, but it was about the only place I could easily keep up with my friends.

For a while, I wrote pretty regular posts, keeping people in the loop for what was going on in my life and staying in touch and processing my grief out loud. When my father died, I stopped writing anything of real substance. There was too much at first, then there was too much to catch up on, then there didn’t seem to be a point. I stayed in the loop and kept an eye on what was going on with my friends, but my usage had changed.

As my usage of Facebook moved from journaling and staying in touch to idle consumption, I felt my time wasn’t being well spent.

So, I’ve scaled down my usage there, and hope to ramp up my writing here. Maybe it will have substance. Maybe it won’t. But for now, this is where you can find me. It posts into Facebook of course – I can’t ask everyone to meet me here. But at least this way my idle consumption is down.

A11YLint Brackets Extension – My Attempt At Realtime Accessibility Improvement

I do all my coding in Brackets – the open source HTML, CSS and JavaScript editor project started by Adobe.

One of the things I really like about Brackets is this integration they’ve done with JSLint – a tool that looks at your JavaScript while you’re writing it and tells you when you’re doing something you probably shouldn’t. JSLint can be a little over-strict sometimes, but using it has had the real benefit of forcing me to write cleaner and more consistent code.

I’ve had an idea kicking around for a little bit that plugging a linter for accessibility into Brackets might help me do the same thing when I’m writing HTML (which I don’t do that often). So this past weekend I sat down after talking the idea through with a couple people and banged something out.

The A11YLint Brackets Extension is available on Github, is MIT licensed, and may or may not be doing all the right things. I’d love it if you checked it out and gave me some feedback. I know it’s incomplete, but it’s a start.

Want to help, but don’t know where to start? Write me some failing tests – create an HTML page that fails a rule not currently covered by the A11YLint Brackets Extension and submit it. Or open a bug and describe the test.

Also – I don’t know what your development process is like, but while I was working on this project I decided to shoot some video along the way, and what came out the other end is this.

Questions, comments, etc – I’d love feedback on this.

Are you a non-profit? Do you need help with mobile? Come see me.

Last night I followed a link to a non-profit on my phone, and it kinda made me sad. No, I won’t name names or anything, but my guess is that if you were to pick 3-4 of your favorite not-huge non-profits, and you went to their website on your phone, you’d probably see what I mean. A lot of non-profits could use a little help making their content easier consume on mobile devices (or easier to consume in general).

And I’m already doing this thing with Red Rover Open Device Lab where I’m working from locally owned bay area cafes on Wednesdays. It seems like it would be a good opportunity provide a little assistance for non-profits in this area.

So, I announce a little thing today to basically say “Come out wherever Red Rover ODL is, I’ll help you if I can.” I don’t know if it’s useful or not, but I know if I don’t make the offer, there’s know way to know who would accept.

So, here it is bay area non-profits: if it’s Wednesday I’m probably sitting in a cafe, and I’m willing to help you crack this particular nut.

Writing Accessibility Into A Design Application

Note: This might be an especially good post to remind people that I’m blogging on my own, and anything I say here isn’t on behalf of my employer.

I pushed out an update today to the Edge Inspect Chrome Extension that mainly included a couple of localization tweaks and adding accessibility tags to the extension.  Given that Edge Inspect is primarily a tool for designers, we had some discussion about if this was even necessary.  I don’t know if I have anything new to say on the subject, but I thought it was worth writing about.

I’ll preface by saying that I’m not the guy to talk to about accessibility and your content.  I’ve never given it much thought before, and I’m pretty sure what you’re reading right now doesn’t give you much in the way of accessibility features unless it came baked into the theme already.  In fact when I typed that I had to go back and set the title of that link I posted earlier because I skipped that bit.  In short, I’m probably part of the problem in the first place.  I know that accessibility doesn’t mean “usable by the blind” but I’m probably not getting even that right.

So when the question of adding accessibility tags to Edge Inspect came up, I was one of the first to say “It’s a visual design tool.  It’s not something you can use if you’re blind.”  The discussion went back and forth, and ultimately we decided to go ahead and do the work.  Partially on the strength of our product owner, who felt strongly that we should do it as a matter of principle, and partially because the company has a dedicated team of people willing to do a lot of the work for us.  Most of the updates to the extension weren’t done by anyone on the team.  It’s hard to say no to free work, especially when it’s really well done.

But the conversation in general forced me to challenge a fundamental assumption I’d made about the product, and in a way that really clicked with changes I’ve been trying to make in how I approach everything.  Like most of us I guess, I used to think I could get to the right solution if I thought things through hard enough.  I’ve come around to the notion that really the only way to get to a good solution is to test an assumption.  In other words there is either stuff I’ve validated, or stuff I haven’t finished testing yet.

And in this context, I’d assumed that Edge Inspect wouldn’t be used by the blind, and never bothered to test that assumption. Further, we’d kinda made it impossible to test the assumption by not including accessibility in “those things we do along the way rather than bolting them on at the end.”

So I guess there were two lessons really.  The first is that we were a little backwards on our thinking.  We were saying “It’s a visual design tool, therefore no blind users” when we probably should have been saying “Users could be blind, how can we make this design tool useful to them.”  And the second is if we’d been thinking that way all along, we wouldn’t have needed to try and bolt the work on at the end.

Will it make any difference to our users, downloads, market impact, adoption rate or revenue?  I dunno.  But I’m pretty sure if we don’t test things like this, we’d never really know for sure.

Note: Edited to add a link to the accessibility team who did the work for us. If you’d like to learn more about the company’s accessibility team, you can read more about them at http://www.adobe.com/accessibility

How Not To Do A Blog

Three posts last year, right? That was a record for me!  And one of them was a shill for an article I wrote.

This year should be better.  I’m not going to put stuff up here just to put stuff up here, but I expect to be more active.  Maybe one a week.  Ish.  We’ll see.

I’m totally not just putting this post in here so that it looks like I’m more active than last year though.  That’s just the impression you’re getting because I didn’t actually say anything meaningful in this post.

World Class Writing Right Here Folks.

Belated SXSW Wrapup

In all the madness surrounding my venture out to SXSW, I didn’t really get a chance to post second impressions or a wrapup.  Better late than never, right?

All in all, the Adobe Shadow launch went great.  I was able to follow along on Twitter while the main presentation was going on, and reactions were very positive.  The same has been true since then.  Not that there aren’t detractors or people who want it to work differently.  But overall, people have been really happy with the product.  I can’t wait until we drop our first update.

SXSW as a whole has left a big blur in my memory.  There was so much to see that a lot of it ran together.  And I’m pretty sure that didn’t have so much to do with free drinks.  Having had some time to reflect, I think the main couple of things I took away from it were these two things:

1 – Have Some Semblance Of A Plan.

I should have scoped out the sessions a little better.  There were a couple I’m bummed that I missed, and a couple that I could have skipped.  If I’d done my homework, my session experience would have been a little better.

2 – Expect To Throw Out The Plan.

Rigid schedule?  Not so much.  If I hadn’t rolled with it, I wouldn’t have met some of the awesome people that I did.  So while I’d like to know ahead of time what my options are, I’m not going to break brain trying to come up with the perfect plan.  I’ll just throw it out when I meet interesting people anyway.

Overall, I really walked away with the feeling that there’s no reason I couldn’t be on a stage instead of in the audience at least once next year.  I’ll have to start honing my pitches for the frenzy come June.

All in all, you should go.  At least once, if you can.  See what people are talking about.  It might not be for you, but I think of it like most large events: you can have as good or as miserable of a time as you want to.  And me, I had an AWESOME time.

First Impressions of #SxSW, Austin and the Adobe Shadow launch.

I got the opportunity to go to SxSW for the launch of Adobe Shadow this year.  This was a whole bunch of first-times for me – the first time I’ve been to Austin, to SxSW, the first time I’ve been present for a big launch, the first time I’ve been involved in such a high profile way in a new product.  I wanted to write a blog post every day about how it was going, but it’s been pretty crazy.  Here’s a bunch of my early thoughts, in no particular order.

Austin looks much more like Ohio than I expected it to.

As crazy as I knew SxSW would be, it’s s much crazier.  In every sense of the word.

When they talk about Austin being theLive Music Capital of the World, they aren’t messing around.

There are some amazing things to be heard at this conference.  And there is a great deal of snake oil.

I would not want to come here to launch an indie game.

I have walked far more in the last few days than I expected to.

This is a cool town to run in.  But it is not flat.

There is such a thing as eating too much delicious meat in one day.

There are so many parties, and so many places to have parties.

Signal to noise is an issue.

Getting here early to pick up my pass saved me half a day of waiting in line.

I want to present here.  Next year.

I’ve heard at least two people mention in a talk concepts that I’m actively researching.

Everyone here wants something.  Coming in knowing what you want is important.

Texas Chili Parlor

Javascript has made a crazy comeback.  Everyone knows it, but it’s still a bit surprising.

Getting noticed here isn’t hard.  Getting noticed on a big scale must be.

SxSW is not a good venue to meet people in the morning.

Really nice boots are expensive.

It’s not always hot here.

Pack extra socks when it’s raining.

There are some amazing people here to be met.  You won’t meet them if you don’t say hi.

Don’t burn out too quickly.

Don’t count on free time.

I’ll post more when I can.  It’s been pretty busy here.