Just a Theory

By David E. Wheeler

Posts about Google

Byline: A Case Study Apple and Google Philosophical Differences

My favorite iPhone feed reading app is Byline by Phantom Fish. It syncs really well with Google Reader, so that things stay more-or-less in sync with NetNewsWire on my Mac. Unlike NetNewsWire, which added Google Reader syncing in 2009, Byline was built with Google Reader syncing from the beginning. Version 3.0 is especially good; I love the ability to swipe between posts. And the killer feature is the archiving of all content after a sync, so that everything loads fast — or on cross-country flights. News junkie that I am, Byline is one of my most-used apps.

Byline Edit Mode

Another great feature is Byline’s edit mode. When looking at a long list of new posts in a particular feed (for me it most often happens with the CPAN Uploads feed — CPAN gets a lot of uploads every day!), most of which I don’t care to read, I tap the “Edit” button to enter edit mode and then start tapping the blue dots to mark a whole bunch of items as unread. But not all of them; I leave the ones I’d like to read. But there’s a problem. At the top of the screen, directly above the top read/unread toggle button, is a button labeled “Mark All as Read.” As soon as you tap this button, Byline exits edit mode and shifts back to the main screen.

It’s a handy shortcut if you actually want to mark all as read. But what if you accidentally hit it, as I’ve done, oh, 20 or 30 times? Well, easy, right? Just go back into that feed, enter edit mode again, and then go over the list again and mark those you still want to read as unread, right? Yes, except for one thing: if Byline syncs before you’ve had a chance to read those posts you’ve just marked as unread, they automatically get marked as unread again. If you’ve elected to include unread items in Byline (it’s a setting), you can’t tell which ones were magically marked as unread by the sync. And if you don’t have unread items included in Byline, those items are just gone.

This has annoyed me many times.

In fairness, it’s not entirely Byline’s fault. One of its design philosophies is to use the Google API eagerly. So as soon as you’re done reading something, it’s marked as read, whether or not the app is actively syncing to Google Reader. This is handy because it means as soon as I’ve read something, if I sync NetNewsWire on my desktop, it’s marked as read there, too. It minimizes the appearance of duplication.

@phfish: “@theory I think they do it for performance reasons. It is a bit of an irritation, though.”

One of the APIs it calls ASAP is Google Reader’s “Mark All as Read API call”, and as Phantom Fish has said, Google provides no way to un-do that call. The result, for me at least, and certainly other users, is the loss of unread items.

I’ve had an interesting Twitter conversation with Phantom Fish about this issue this morning, trying to brainstorm ways to work around it. For me, I’d like to see either a confirmation button when I hit “Mark All as Read,” or have it not immediately leave edit mode but turn the “Mark All as Read” button into an “Undo” button, so that I have a chance to undo the marking all as read while still in edit mode, before the API call gets sent to Google. Phantom Fish is understandably reluctant to make a change such as this, however, because so many people like and have requested the single-tap to mark all as read. There are users who want both things. And Phantom Fish is reluctant to add a setting for such a feature, and indeed, I also tend to favor convention over configuration.

It’s a bit of a thorny issue, but one that I think nicely highlights the philosophical difference between Apple and Google. On iOS, I’m used to nothing I do while in an edit mode being committed until I hit the “Done” button. Byline’s “Mark All as Read” button short-circuits this behavior by ending the editing without me hitting “Done,” and instantly calls the Reader API. This is very convenient for power users (who never hit the “Mark All as Read” button accidentally, I guess), and strongly reminds me of how Geek-oriented Google applications like Reader are. I’m guessing such power users are Google Reader users. I’m not, I just use it for syncing.

The emphasis of “Mark all as Read” and its underlying API is ro “get things done in as few steps as possible.” This contrasts with the Apple philosophy exhibited in iOS, where things should of course be done as efficiently as possible, but where, I think, the principle of least surprise is emphasized. It’s handy to mark all as read with one tap, unless you didn’t want to, in which case it’s surprising that you can’t get the unread items back—specially since you never told the app you were done editing. Google Reader power-user types want the convenience of one tap. Folks like me, used to the relatively low levels of the unexpected on iOS, want things to change only when we say we’re ready for the change.

Anyway, I expect that Phantom Fish will work out some way to deal with this issue. (Frankly, I’d welcome the ability to exclude certain feeds from Byine, as NetNewsWire for iOS does, so that I don’t have to bother with some feeds on my iPhone, but that’s a different feature request.) But I thought it was interesting, in discussing the issue, how UI philosophical interests can conflict. Frankly, I think that iOS apps should be more iOSy in this respect (in all other ways Byline is very iOSy), but others disagree, and it makes for an interesting conversation.

Looking for the comments? Try the old layout.

Search Powered by KinoSearch

On a whim yesterday, I decided to give KinoSearch a try. I’ve had the module installed from CPAN for a while, so I can say that it installed very easily. So then all I did was to cut and paste the sample programs from the tutorial, tweak a few things for my blog entries, and try it.

And lo and behold, it worked! After a mere 30 minutes work, it worked so well that I was willing to spend the couple of hours it took this morning to get the results nicely formatted wrapped in my Blosxom templates. So now this site is fully indexed and searchable, and all I have to do is reindex it every time I publish a new entry. So now the search field at the bottom of every page uses KinoSearch, or you can just go to the search page to perform the search. Sweet!

So give it a try. Search for “iraq” or “svn” to see how it works. And check out those KinoSearch benchmarks, too. This thing is fast!

Looking for the comments? Try the old layout.

Has Google Forgotten its on Tagline?

My friend Chad Dickerson, the exiting CTO of Infoworld, has blogged about a recent move by Google to patent advertising in RSS!

Incorporating targeted ads into information in a syndicated, e.g., RSS, presentation format in an automated manner is described. Syndicated material e.g., corresponding to a news feed, search results or web logs, are combined with the output of an automated ad server. An automated ad server is used to provide keyword or content based targeted ads. The ads are incorporated directly into a syndicated feed, e.g., with individual ads becoming items within a particular channel of the feed.

This despite the fact that InfoWorld was itself sending targeted ads out in is RSS feeds before Google filed for its patent! Is this another one-click debacle in the making? Does it really make any sense to patent delivering targeted ads over HTTP just because they’re in XML instead of HTML?

What do you think?

Looking for the comments? Try the old layout.

How the Bricolage Summer of Code Projects were Selected

As you may have read, we got quite a number of applications from students wishing to contribute to Bricolage as part of Google’s Summer of Code initiative. Quite a few of them were very good. There were eight projects I wanted to accept, but, Bricolage was allocated only four projects. Of course, this is four more than we would have had otherwise, and I’m really excited to be working with them this summer.

The four winning projects are:

  • Add Input Channels, by Marshall Roch
  • New Sample Document types and templates, by Scott Loyd
  • Port Bricolage to Apache 2/mod_perl 2 and Windows, by Sam Strasser
  • Port Bricolage to MySQL, by Tamas Mezei

The other projects I wanted to get but could not were:

  • Add Bulk Edit, Bulk Media Upload, and Site Tags, by Andreas Hofmeister
  • Element Occurrence Specification, by Christian James Muise
  • Add JSP Templating, by Adrian Fernandez
  • Update and Modernize the Installer, by Yiannis Valassakis

I am hoping that some of these students might want to work on their projects, anyway. I’ve even found other developers to help with the mentoring of JSP templating (Patrick LeBoutillier with Perl/Java voodo) and the installer modernization (Sam Tregar of Matchstick fame). Unfortunately, I’ve not heard back from any of them after sending them an invite to participate in the project. C’est la vie, I guess

The hardest part of the proposal evaluation process was selecting from the 20 proposals to port Bricolage to MySQL. Ultimate, there were four excellent proposals for this project. Reading the proposals over and over, I couldn’t decide between them. Ultimately, I sent an email to the four top contenders with the following items for them to reply to:

  1. Please describe in a line or two your Perl knowledge or experience (if any).
  2. Please describe in a line or two your MySQL and PostgreSQL knowledge or experience (if any).
  3. Please describe any previous Bricolage usage experience.
  4. Please describe any previous Bricolage development experience.
  5. Please describe any previous Open Source development experience.
  6. What school do you attend?
  7. What is your specialty at the school?
  8. How many years have you attended there?
  9. How much time do you expect to have for this project?
  10. Have you applied for any other Summer of Code projects? If so, which ones?
  11. Your personal or professional web page URL (if any).
  12. Would you be willing to collaborate with another developer who might be working on a SQLite port to ensure that your changes can fully inter-operate?
  13. Please outline your project plan for porting Bricolage to MySQL, including a description of what parts of the Bricolage API, DDLs, installer, and upgrader would need to be modified to complete the project.

For better or for worse, all four applicants responded with detailed answers to my questions. They were all great, and that made it even harder to select just one of them. At this point, there were only a few hours left to rank applicants in Google’s SoC Admin Web app, so I figured I had to get more objective—or at least fool myself into thinking I was.

So I decided to rank each applicant from one to five for each question, and then add up all of the results and see who came out on top. So now I was comparing answers to a single question between applicants, and filling in scores for them in a spreadsheet. As it was, things were still really close; yes, all of the students where that good! Tamas came out on top with a score of 30, two others were tied at 28, and the fourth applicant scored 26. They were close enough that I wanted to review them all one more time, this time paying specific attention to the last item in my questionnaire, the project plan.

Each of the four applicants had taken the time to read the mail lists and had looked at the existing Bricolage code. But there were varying levels of detail and demonstration of knowledge for how to implement the MySQL port, but Tamas did come out slightly ahead on this item, so I gave his proposal the green light.

But in truth, I would have been happy with any one of those four applicants. I was only sorry I had to choose only one! If Google does this again, I think I’ll list many more project ideas on the Bricolage Web site, and try to steer people to the mail lists to discuss their ideas before sending them in. Then I might end up with 11 great applications!

Looking for the comments? Try the old layout.

Bricolage a Google Summer of Code Project

The Bricolage project is pleased to have been selected to be a partner in the Google Summer of Code. This Initiative is designed to introduce students to the world of Open Source Software Development and provide them with a $4500 award for completing an Open Source project before the end of Summer.

As a partner, we are currently looking for student volunteers to propose Bricolage development projects. We have created a list of suggested project ideas. If you’re interested in hacking on Bricolage for fame and fortune, join the Bricolage Developers mail list or sign on to #bricolage on irc.develooper.org (MagNet) to outline your proposal and get feedback as you prepare to submit it to Google. You can also join the Google Summer-Discuss group or sign on to #google-summer on irc.freenode.net for more general discussion of the Summer of Code.

But hurry, the deadline for proposal submissions is June 14! Students who get Bricolage projects accepted will be mentored by me and other members of the Bricolage community.

We look forward to your proposals!

Looking for the comments? Try the old layout.