Wednesday, June 16, 2010

Brightkite Tries Another Angle

Brightkite-provided image of their tip screen.

Brightkite is working to be more relevant to the average web surfer using its image-happy almost-food-centric users by allowing them to post tips to venues (Tippety Top. Brighkite launches photo-tips). Oddly, as a Brightkite user, I first heard about this from Mashable (Brightkite Launches Location-Based Photo Tips), and then pestered Brighkite about this until it posted the announcement to the official blog hours later (I'm not implying that I caused Brightkite to post it, I am not that awesome).

Brightkite does not share venues with Foursquare or Gowalla, but thanks to its Check.in service, which allows you to check in to all three services at once, we know they are capable of matching places. Unfortunately, the new Photo Tips feature doesn't leverage the Check.in service (or its functionality), meaning it really won't lure users from Foursquare or Gowalla to use it in place of (or in addition to) their current check-in and tip-posting behavior on those services.

No tips? With all those photos I've posted?

Looking through this new feature, I also cannot figure out how to turn old photos into tips, and while I asked Brightkite on its blog post and via the service (and Brightkite is usually rather responsive), I've heard nothing back yet. That means a couple years of tracking food at my favorite local Italian restaurant isn't being treated as a tip for that venue.

New photos can be updated and flagged as a tip right off the bat. Unfortunately, I use a Windows Mobile phone, where there is no Brightkite app, which means I have to email my photos into the service. Using this method, there is no way to flag a photo as a tip, making my first issue more important.

How this may integrate with services like Loopt, Foursquare, Gowalla and so on is anybody's guess. As a user, you really need to have some familiarity with the site to find tips, and there is no indication how they will make this repository available through Google or other similar search engines for users who have never heard of Brightkite. Interestingly, I currently add tips to a venue in Foursquare and add the URL of my Brightkite photo. It's not efficient, but it's some way to share the data. I will continue to use that method until I can see how this new feature will actually work.

Friday, June 11, 2010

Blind Students Sue Over Online Law School Applications

National Federation of the BlindThe Chronicle of Higher Education reported that three law students and the National Federation of the Blind (NFB) are suing four law schools in California claiming that the online application system is not accessible to students who are blind (Blind Students Sue Law Schools Over Online Applications). Specifically, the online application lives at the web site of the Law School Admission Council. The four colleges drive applicants to this web site to complete online applications. The first version of this suit started in February 2009 with the NFB and one student suing the admission council, but was just modified to add more plaintiffs and defendants. NFB issued a press release on Wednesday outlining its position.

The outcome of this case may be closely watched, since there is a lack of case law that defines how ADA and Section 508 compliance can and should be implemented. Given the regular debate between web developers and accessibility advocates about the nuances of the meaning and application of assorted web technologies to achieve maximum accessibility within a web site.

Back in 2008, many of us watched the lawsuit between Target and NFB for just such an example of case law. Instead, they settled the lawsuit and NFB walked away at least $200,000 richer. As it is, Target was really only accountable for making the site more accessible to the blind, not all users. The WebAIM Blog (Target lawsuit settled) outlines some of the reasons that lawsuit didn't do much to advance accessibility compliance or understanding, certainly not past providing for the blind.

Prior cases that started off as high profile (in the world of accessibility) such as the Sydney Organising Committee for the Olympic Games' (SOCOG) 2000 Olympic web site and America Online (its software more than its web site) were also settled without clear direction for accessibility practitioners. In both of these cases, the complaints were also filed by blind users and changes were made that in retrospect are almost laughably easy (they were then, too) such as adding alt attributes to image tags.

Given the prior history that these cases settle, and given that NFB might be more motivated (based on the pay-outs from the Target case) to settle than to use this as case law for the rest of the web, I don't expect to see anything terribly useful coming from this case. Even if it did, it will still likely only address accessibility for the blind, leaving other disabilities out of any potentially useful case law.

Wednesday, June 9, 2010

Google Caffeine Is Live

Illustration showing difference between old and new Google index.

Late yesterday Google announced the launch of its new web indexing system, Caffeine. According to Google, it provides 50% "fresher" results and is the largest collection of web content it has ever offered.

The big push for this new indexing technology is the rise (explosion, really) of real-time data on the web. With Twitter acting as a de facto news source for so many, and with other services such as location-based social media, rapid-fire blogs, mailing list archives and the like pushing data live at an ever-increasing rate, Google's old model of updating once a week (or every two weeks) just wasn't cutting it. We've seen Twitter integrated into Google search results already, but that has been strapped on to results that were otherwise out of date.

Google provided the image you see at the top of this post as an example of how the old index worked compared to how Caffeine works. Unless you speak blocks and the Bohr model, it really doesn't say much (except that I worry about the little guy in the cloud taking a camera to the head). The gist is, the old index was built in layers, with some content being refreshed more regularly than other content. Sites like CNN might live at the top of the index, being refreshed regularly. Sites like my personal pages might live at the very bottom, only being refreshed when someone goes in with a shovel to scrape the cruft off the edges of the database.

With Caffeine, they've flipped all that over. The crawler is always out, always indexing, and it's always updating the index. Whether it makes it to your site today or tomorrow is unknown, but now at least it's more likely to be picked up sooner rather than far far later. This is how Google describes it:

Caffeine lets us index web pages on an enormous scale. In fact, every second Caffeine processes hundreds of thousands of pages in parallel. If this were a pile of paper it would grow three miles taller every second. Caffeine takes up nearly 100 million gigabytes of storage in one database and adds new information at a rate of hundreds of thousands of gigabytes per day. You would need 625,000 of the largest iPods to store that much information; if these were stacked end-to-end they would go for more than 40 miles.

As a searcher, you may find that you are getting more timely results more regularly. The effect may not be immediate, however. I have already been trying it out, but my tweets aren't really a good example.

Tuesday, June 8, 2010

TED Talk: The Future of UI

John Underkoffler is the science adviser who was behind the user interface ideas used in the movie Minority Report. In his TED talk, he shows examples of interfaces made up of real-world objects, providing interaction far different than what we know today. Given the success of the Wii, multi-touch interfaces, and the coming controller-free Project Natal for the Xbox, this shouldn't seem too far-fetched. How these ideas will be polished and ultimately deployed will depend on many factors, including what hardware manufacturers are willing to support. This is a talk about ideals, so don't expect to see much of a nod to accessibility for people with mobility impairments, although that will certainly be one of the issues to be addressed before this can see general use.

Monday, June 7, 2010

Luke Wroblewski on Mobile First

Image of video, complete with 'Play' arrow awkwardly placed on his face.

Dan Benjamin and Jeffrey Zeldman interview Luke Wroblewski about the evolving nature of the web as mobile devices start to dominate the stats of some sites (5 by 5: Episode 6: Mobile First, 51:37). They bounce around discussing issues from design to technology while Luke peppers the conversation with statistics about mobile use. Overall, the pitch is that designing for mobile platforms first helps circumvent some of the issues of having to rebuild a design to work for mobile (see his original article, Mobile First).

The next day Luke wrote up an article where he takes some of his points from the interview and expands on them (Mobile First Helps with Big Issues). One of the points from the interview that he expands on is the idea of how a limited screen size forces a developer to prune to the most necessary bits (navigation, functions, etc.).

When you are working with a 320x480 pixel screen (iPhone, Palm Pre, first generation Android phones), 80% of the screen space you had at 1024x768 is gone. [...] Losing 80% of your screen space forces you to focus. You need to make sure that what stays on the screen is the most important set of features for your customers and your business.

Another point he expands on is the idea of making web sites appear and function the same in every browser. Web developers have struggled with that for years and it's an expensive proposition for many organizations to support. He (and Zeldman bolsters it in the interview) argues that consumers are starting to realize that web sites can look different in different browsers, and in many cases should look different. This logic expands (in the interview) to address browsers like Internet Explorer 6 and other legacy platforms.

The onset of many networked consumer devices with different capabilities and limitations has begun to open a lot of people's eyes to the fact that Web sites don't have to look and act the same in every browser. In fact, they shouldn't. Designing for mobile first establishes that up front.

In the interview, Luke points out that in 2009 over a million touchscreen devices were sold per day. He has a new post today with updated statistics on the mobile market (Data Monday: Mobile Market Update). Some of the other data points:

  • Worldwide mobile phone sales to end users totaled 314.7 million units in the first quarter of 2010, a 17 per cent increase from the same period in 2009, according to Gartner, Inc. Smarpthone sales to end users reached 54.3 million units, an increase of 48.7 per cent from the first quarter of 2009. (source)
  • Growth in the mobile devices market was driven by double-digit growth of smartphone sales in mature markets. Smartphones accounted for 17.3 per cent of all mobile handset sales in the first quarter of 2010, up from 13.6 per cent in the same period in 2009. (source)
  • As of Q1 2010, Nielsen data shows that 23% of mobile consumers now have a smartphone, up from just 16% in Q2 2009. Nationally, the iPhone's still in second place, with a 28% market share compared to RIM's 35% (Android has 9%; Windows Mobile has 19%). (source)
  • 14% of mobile subscribers have downloaded an app in the last 30 days. (source)
  • Facebook, Google Maps and Weather Channel are the most popular apps across smartphones. iPhones: Facebook (58%), iTunes (48%), Google Maps (47%) Android: Google Maps (67%), Facebook (50%), Weather Channel (38%) Blackberry: Facebook (51%), Google Maps (34%), Weather Channel (28%) (source)
  • Nearly 5 million consumers downloaded the new Skype iPhone app in four days. (source)
  • eBay's iPhone app has been downloaded 10 million times, and the company expects $1.5 billion to $2 billion in transactions to be conducted using the mobile application this year. The eBay iPhone app was responsible for $600 million in volume last year. (source)

Friday, June 4, 2010

The Future of Check-ins (at evolt.org)

Last week Mashable featured a post asking if location-based services are all just hype. Continuing the geolocation theme Mashable has a new post, What the Future Holds for the Checkin, by a guest blogger/columnist. I have a reservations about how well this article delves into future opportunities, so I just toss a few out here.

Please header over to evolt.org to read my article, The Future of Check-ins. It will only be there for eternity, or until the world ends, so make sure you head over there soon. To make sure you see this link, I am repeating it:

Read The Future of Check-ins at evolt.org

Thursday, June 3, 2010

SVG Progress Bar Contest

SVG iconThanks to the W3C Twitter feed, I discovered a W3C blog post about an SVG contest, "No Bit, Sherlock." While the W3C may be pushing the contest, they aren't the sponsors. The contest is produced by Web Directions, an organization founded by John Allsop and Maxine Sherrin to create web developer conferences around the world. They pushed Microsoft UK to pony up some prizes for a contest, owing to Internet Explorer 9's plans to support SVG, something sorely lacking in all prior versions of IE (you can grab an Internet Explorer 9 preview release if you really want SVG now).

The gist of the contest is simple: Create a progress bar in SVG. Contestants are allowed leeway in how it looks and functions, but it must adhere to two key elements:

  1. It must indicate to a user when waiting in an indeterminate state, and
  2. it must indicate to a user how much a process has progressed.

Here's the catch: It must be submitted by June 11 at 2pm, British Summer Time (yeah, I'd have to call someone in Britain, too). The date was probably chosen to coincide with the Web Directions @media conference in London, June 9-11. You can read John Allsop's blog post about the contest and why they thought it up.

The criteria, from the "No Bit, Sherlock" site:

  1. Your control has to work acceptably in the latest versions of Opera, Safari, Chrome, Firefox, and Intenet Explorer 9, so it would probably make sense to at least give it a look see in all these browsers.
  2. Your SVG has to validate.
  3. The judges will also pay attention to accessibility factors - hint - investigate the ARIA role attribute.
  4. And, they'll take a quick peak under the covers at your code, so the cleaner and more legible that is, the better
  5. They'll also consider how well the control communicates the two states described above, how attractive it is, and if it has that x-factor, then all the better.

Further details, including the list of judges, prizes, and even some SVG resources are all at the contest site. If you are new to SVG, I suggest you take a look at the SVG information at the W3C site.