Travelogues, Places and Meetups

Today on ReadWriteWeb, Marshall Kirkpatrick (Co-Editor and Vice President of Content Development) has posted an article titled Why We Check In: The Reasons People Use Location Based Social Networks. In the article he explores why people use services like Foursquare and Gowalla to post their physical location for the world to see. Given that Facebook is planning to add location features and Twitter is pushing its own Twitter Places feature, this is a question many people ask — including those who use the services. As a regular user, I am often asked why and this time I had an opportunity to provide an answer for this article.

Marshall put the question out on the Twitters (yes, I am being ironical), and thanks to a retweet, it came my way. I responded with a couple tweets (below) about using Brightkite as my own travelogue. I thought what I was talking about was relatively unique. Apparently so did Marshall, because he comments on how many people made similar statements, about how they also used these services as some form of personal history.

My ego aside, which I suspect we all know is no small task, the article also discusses how the game nature of some services motivates people, while the human connection (almost forced serendipity) is a motivator for others. While the article isn't exactly scientific (at all), his polling certainly demonstrates some trends. Though there are no big surprises, the anecdotal examples are interesting.

Meanwhile, over at Mashable there is an article discussing Twitter Places, What Twitter Places Means for the Future of Location. You may recall me wondering how Twitter Places in its current form can really take over the world of location-social media in my post Twitter Pushes into Places. Mashable offers some reasons to ponder:

1. Location-Sharing to Become Mainstream
2. Boost Interest in Geo-location Apps
3. Promoted Places

In these examples, it's not that Twitter is going to take the lead, but instead that Twitter is simply going to use its "star power" to popularize and legitimize things we are already doing, or that other services are already doing.

While I've got you thinking about all these interesting bits related to location-based social media (we really need a simpler, universal name for that), take a look at this article from ReadWriteWeb: Is Geofencing the Next Evolution for Location Apps? Location Labs Thinks So. It essentially describes the thing I've always wanted Brightkite to do — notify me when I or a friend have entered some geographic area or zone and let us know each other is there. Certainly there is more to the service than this, but even if all you want is auto-checkins, then you may want to read this article.

If you've made it this far, then you may actually be interested in this stuff. If so, and you are interested in meeting people in your area who play and/or work in this space, Mashable is sponsoring a worldwide social media meetup on Wednesday, June 30. Many cities are getting in on the action. In fact, you could come to Buffalo and participate in our Mashable Meetup. If you don't, you'll be just like the other 6 billion people on the planet, and that's ok.

Read More

HTML5 and CSS3 Confusion

Too often I have found myself trying to explain to people what HTML5 is and how it won't make the web look better. Then I get into a discussion of CSS3 and, other than the standards-obsessed, that's when I lose most people.

There is a post on PC Pro today (The confusion surrounding HTML5) that explains it pretty succinctly, and even lays some of the blame for the confusion at Apple's feet for its highly-publicized Safari-only HTML5 demos. That may be why this stuck out to me. After Apple showed it off, every two-bit basement-dwelling FrontPage-using webmaster-wanna-be decided HTML5 was awesome, completely missing the fact that it was the CSS3 and pretty pictures that really got their attention.

What I like about the post is that the author explains you can use HTML 4.01 with CSS3, or you can use HTML5 with CSS 2.1 (don't limit yourself to those two options, more fun can be had). I don't think this piece will convince those who disagree when I say the same thing, but at least it's easier to share this than wheel me into a room each time it needs to be explained.

If you are stumbling across web sites touting their HTML5 prowess, but the real whiz-bang is how they look, then you can be pretty sure that those sites are also using CSS3. And if you find somebody who claims HTML5 is all that, you can explain that without CSS3, it's not. At this point, HTML5 is an unfinished spec that simply defines structural and semantic elements and doesn't have a thing to say about style. Nor will it.

Read More

W3C Browser and Accessibility News Bits

Three bits of news from the W3C this week related to browsers and accessibility. Well, two about browsers and two about accessibility with one of them acting as my cross-over reference.

The User Agent Accessibility Guidelines Working Group has published an updated Working Draft of the User Agent Accessibility Guidelines (UAAG) 2.0. This is not the same as the Web Content Accessibility Guidelines, but instead this is targeted at browser makers and other makers of software for remote viewing, such as media players, RSS readers, and so on. The intent is to outline the standards they must meet to be accessible to people with disabilities. W3C is looking for comments now before "last call" (your last chance to weigh in). There is also a working draft of the Implementing UAAG 2.0 supporting document, which is at least worth a glance over the main guidelines.

If you are somehow connected to the process of making a web browser, or are just oddly curious, W3C has created a new mailing list for fostering discussion related to web browser performance. It's brand new, so as of this writing there are no posts other than a test post and unsub instructions. You can check it out, and perhaps if it grows, even join it at http://lists.w3.org/Archives/Public/public-web-perf/.

Bringing it back to accessibility, the Web Accessibility Initiative (WAI) Education and Outreach Working Group (EOWG) published a document to help you make presentations, talks, meetings, and training accessible to all of your potential audience, including people with disabilities. W3C announced it on its blog (Make Your Presentations Accessible to All) and provided a link directly to the document, How to Make Presentations Accessible to All. To steal a bit from its intro, the general gist is that presenters should be aware that some of their audience might not be able to:

• see well or at all,
• hear well or at all,
• move well or at all,
• speak well or at all, or
• understand information presented in some ways well or at all.

In short, speakers need to describe pertinent visual content, speak clearly into the microphone, ensure the facility is accessible, and consider the other points below (go read the document to see the other points).

Read More

Twitter Pushes into Places

Earlier this week Twitter announced Twitter Places, allowing users to associate tweets with specific places, not just latitude/longitude or data pushed in from other services (Twitter Places: More Context For Your Tweets). Up until this announcement, you could associate a tweet with a specific place by pushing a location with the tweet, as Brighkite does when it pushes an update to Twitter. Twitter even made best-guesses from your latitude/longitude to regions on a map (such as "central business district" or general community names). Now the Twitter web site and mobile site will support this feature so you don't need to rely on an additional application. The mobile applications, however, do not yet support it.

Twitter has said it is working on an API to allow developers to integrate Twitter places into their applications. In addition, even more browsers should support the ability to add your location to a tweet thanks to some partnerships with other providers. Twitter has also claimed Foursquare and Gowalla integration:

Foursquare and Gowalla integration: Many Foursquare and Gowalla users publish check-ins to Twitter. Location is a key component of these Tweets, so we worked closely with both companies to associate a Twitter Place with Tweets generated by these services. This means that if you click on a Twitter Place, such as "Ritual Roasters," you will see standard Tweets and check-ins from Foursquare and Gowalla.

When I bring up the "add your location" menu in Twitter to see my options for a place, my current venue (Algonquin Studios) is not in there. I know the venue exists in Foursquare, Gowalla and Brightkite, but it is not an option for me. I checked in to Algonquin Studios using Foursquare, Gowalla and Brightkite (just in case you need to somehow initialize a venue in your list of options) and have pushed tweets from Foursquare and Brightkite from this venue. But no luck, it still doesn't show up in the list.

Given that I already use location-based services to track my posts, there is nothing in the Twitter Places feature, as of yet, that will move me away from them. The fact that I cannot even select a valid location means I probably won't be trying this feature again for a while.

Read More

Brightkite Tries Another Angle

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.

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.

Read More

Blind Students Sue Over Online Law School Applications

The 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.

Read More

Google Caffeine Is Live

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.

Read More

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.

Read More

Luke Wroblewski on Mobile First

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)

Read More

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

Read More

SVG Progress Bar Contest

Thanks 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.

Read More

Smokescreen Brings Flash to iPad, iPhone

Smokescreen - iPad demo #1 from Chris @ RevShockAds on Vimeo.

Now that it's clear that Apple has no intention of letting Adobe Flash run on the iPad or iPhone, workarounds for Flash are even more compelling to developers. Smokescreen, primarily by Chris Smoak, bypasses the need for the Flash plug-in by pulling in the SWF binaries and decompressing them in JavaScript, yanking out the images and audio and putting it all back together with the vector data rendered as animated SVG. Simon Willison got the details and posted the technical process on his blog:

It runs entirely in the browser, reads in SWF binaries, unzips them (in native JS), extracts images and embedded audio and turns them in to base64 encoded data:uris, then stitches the vector graphics back together as animated SVG. Open up the Chrome Web Inspector while the demo is running and you can see the SVG changing in real time. Smokescreen even implements its own ActionScript bytecode interpreter.

You can see demos of Smokescreen running StrongBad emails and ad banners at the site. If you are running Internet Explorer (any version), then these demos won't work for you. In general, you'll need the most recent versions of Firefox, Safari, Chrome or Opera to see the demos. A couple of them run on the iPad or iPhone and there is even a video of it in action for those who don't have either device (see above).

The Flash movies don't run quite as quickly using Smokescreen as they would in the native Flash player, but that's to be expected when all the work is offloaded to the browser's JavaScript engine (8,000 lines of code weighing in at 175kb). I also noticed that sometimes text embedded in the SWF file either didn't appear at all or had some odd anti-aliasing. Given how new this is, however, I suspect these are surmountable obstacles. Given that Chris plans to release the code as open source, more developers will likely be able to contribute to pare this down.

What would make this even more interesting is if Adobe lent its support in some way. Since this has the potential to reverse the trepidation Flash developers now feel thanks to the increase in iPads and iPhones on the web, it may stave off any doomsday scenarios for Flash. It may also blow up Apple's plans to ultimately push Flash out of the market altogether unless they want to stop supporting the JavaScript and HTML5 that this utility uses to render the former-Flash movies. It's still too early to tell which way either company will go with this, if they do anything at all, but I suspect it will be interesting to watch.

Related Links

• Smokescreen makes Flash content visible on iPhone and iPad (video) at engadget.
• Smokescreen Converts Flash to JavaScript On the Fly at Gizmodo.
• Smokescreen Project Promises 'Flash Without the Plug-in' at Webmonkey.

Read More