Cory Bohon

There are a lot of great code snippet sharing tools out there, from GitHub’s Gist to Codepad to any other number of online services. However, a new code snippet sharing service recently peaked my interest called Chop.

Chop is a project created by an interactive design company called ZURB. They have a few different tools on their Playground website. Chop is interesting not only because of its simplicity and ease-of-use, but also because it’s built with Ruby on Rails.

Chop currently has syntax highlighting support for Ruby, Python, JavaScript, HTML, CSS, Java, C/C++, PHP, SQL, Diff, JSON, YAML, ERB, and XML. The service can even grab code from a Git raw page or another webpage just by specifying the URL to the page.

Once you Chop a piece of code, you will be able to send a URL “to your nerds” or … a special someone (although there may be repercussions after sending geeky code to some people). Once you are in the sharing page, you will be able to comment on the code by clicking on the line you would like to edit.

Overall, Chop is a pretty good service that allows you to quickly and easily paste and share a chunk of code while doing that in style. For a free service, we couldn’t really ask more, but I would like to see the ability to download code snippets that have been pasted in.

The Mac, iOS, Android, and Amazon application stores and other places like it have become the go-to destination for many device owners to find and purchase new applications for their devices. But, they are also drawing large crowds of developers. According to Apple, there are over 350,000 applications; and, that number is growing almost daily.

However, the app store model isn’t perfect. I have always come from the persuasion that you need to step back and look at the past in order to gain appreciation and inspiration for future endeavors. Because more and more consumers are using these app store as the primary point of sale and delivery of software, I believe that we should take a step back and look at the app store model in an overall picture to see what things need to be changed going forward. No app store is perfect, and I highly doubt that it ever will be; but, I believe that there are 4 things that, if implemented, would make the app store a better concept in general. Two of the problems are from a developer’s point of view, and the other two are from the consumer’s point of view.

1. Developers and App Store Listings

At the core of any app store is the developers. Without them, you wouldn’t have any applications available for your platform. They are the “bread and butter” of devices. Imagine an iPad without any apps. Not so “magical,” huh?

I think Apple has implemented a great system for developers to get their applications out to the public with a great distribution system. They have also allowed developers to get their applications out to the press, free of charge, with promotional codes that can be downloaded and sent out to reviewer. However, there are things that Apple and others could do better.

First, I would like to see all development platforms provide developers with the ability to download promotional codes. Currently, Google’s App Market doesn’t support this, and I’m sure there are other app stores that don’t.

Second, developers should have the ability to customize their app store listings a little more. Perhaps the ability to use their company logo and colors, or the ability to have an email contact or support form that can be filled out. Before the app stores, customers interacted directly with the developer’s website. Since then, the app store has abstracted the developer, making them almost “the man behind the curtain,” so to speak, when it comes to interacting with customers. No longer do we get to e-mail a customer when they purchase a piece of software, to ask them how they are liking it. We usually only hear from a customer when they are having problems with the application.

2. Comments and Ratings

Comments and ratings are a tough situation. In part, they are a good thing because it allows a customer to express their opinion about the software they just purchased; however, I have seen many customers complain about a feature of the product not working when they just didn’t read the instructions. This bad review can then turn into tanking sales, and suddenly an application you’ve been working months on ceases to turn a profitable number of sales.

Another problem with ratings and comments is that usually the only time a user actually posts one is when they are having problems with the application. Because the app store listings don’t foster a relationship between the developer and the customer, and because most listings on app stores don’t feature contact information for the developer’s support channel, customers feel they should just post their problem into the comments and give the app a bad rating in hopes that the developer will pay attention to the issue.

Here’s the problem, however: Developer’s don’t have access to the comments, or the e-mail addresses of those users posting their problems.

This is why I think app stores should implement some type of CRM (Customer Relationship Management) software so that when a user is having a problem with your application, you will be able to respond to them in the comments to let them (and others) know what is going on and how to solve the issue. Perhaps these messages could be posted publicly, or (if the customer requests), privately.

Regardless, however, developers should have the right to respond to customer’s comments. Especially since we are giving 30% of our revenue (depending on the app store) to the app store, and surely, all of that can’t be going to just hosting of the downloads and credit card transactions.

3. Upgrades

Another thing that really annoys me about the app store is the inability to issue (as a developer) or get discounted upgrades (as a customer) for future versions of the software. Many developers allow discounted upgrades (say, 50% off) for repeat customers upgrading to the newest version (i.e. from version 1.0 to version 2.0) of the software.

To make matters worse, often times when an X.0 upgrade is released for a piece software, the developer takes down the older version, most of time forcing people to upgrade to the new version at regular price. This, of course, leads us to the last problem with the current app store model: Backups.

4. Backups

How many of you have been in a similar situation as this: You purchase an app from the app store, and after a year, the developer decided to upgrade to a new 2.0 release. Because the developer no longer wishes to keep distributing the old 1.0 release, they delete from the app store completely. But, as a buyer of the old 1.0 release, you no longer have access to download the 1.0 release should you wish to in the future. Of course, you can still install the software in the future using a backup stored on your computer, but that is your only lifeline.

My wish is that from a consumer standpoint, Apple and Google would finally see that if you purchase a piece of software it should remain available to you, even if the developer decides to take it down in the future. I further think that even if the app store management decides to take down the software at their own discretion, they should either refund you or allow purchasers to keep downloading the software. It’s not fair to take down the software without any warning, not refund the customer, and then not allow access to the purchase.

What are your thoughts regarding this situation? I think there are other changes that need to be made, but these are just a few big ones. Join the conversation on Twitter or in the comments below. I’m looking forward to your thoughts and comments.

If you’re following my Twitter feed, you probably know that I’ve been ecstatic about a fairly new content management system for Digital Humanists creating digital archives. The web software is called Omeka, and it’s out of the Center for Digital Humanities at George Mason University in Virginia.

Omeka has a rich API (application programming interface) that lets developers and creatives alike create awesome plugins and additional content that flows right along side of the CMS. I have been actively developing Omeka plugins for the past academic year at my university in hopes of making Omeka more accessible to visually impaired people accessing the Omeka archives. The development was sponsored by two grant-related projects that I’m involved with. The first project is LookListenTouch.org which I worked for Fall 2009, and BrailleSC.org that I’m currently working on.

People who are visually impaired generally access websites using screen reading software like JAWS or Apple’s screen reader VoiceOver. This software reads aloud what’s on the screen, but screen readers don’t work well with certain web content, namely Adobe Flash, JavaScript and Java applets. Fortunately, Omeka’s front-end doesn’t rely on any of the technologies, making it pretty accessible out-of-the-box. However, the accessibility plugins I’ve developed expand on the universal design model, making Omeka even more accessible.

The first of the plugins is an Access Keys plugin. This plugin lets the administrator assign Access Keys, which are one-character keyboard shortcuts, to basic Omeka functionality, such as go to the home page, browse by items, browse by collections, skip to next item, skip to previous item, and skip directly to the content. Normally people accessing websites with a screen reader need to listen to a list of menu items each and every time they listen to a page being read, but with the Access Keys model, they can memorize a set of keys, then jump to any page they wish to go to. For example, if you wanted to go to the search page, you can press Control + S and go directly to the search page in Omeka.

Access Keys can provide a ton of usability for user accessing a particular website, making navigation easier than ever before. The thing is, Access Keys have been around since around 1999 — why haven’t they been used before? Well, I’d suggest that’s partially because different web browsers use different modifier keys (i.e. pressing control, command, or shift before pressing the access key in order to activate a link). That’s why BrailleSC.org and LookListenTouch.org is advocating the standardization of modifier keys across different browsers, operating systems, and versions of browsers. This would make life easier for users and developers alike.

Continuing on the idea of Access Keys, I’ve also developed a custom Access Keys plugin that will allow an Omeka administrator to specify up-to 10 URLs and Access Keys that will be available from any page inside of Omeka. For example, you could go to Google.com by pressing Control + G.

Of course, Access Keys are limited to the number of letters and numbers available on the keyboard, so that’s 26 + 10 = 36 available keys. Symbols are not available for assigning Access Keys, and remember that if the shortcut assigned is also a shortcut for the web browser (i.e. in Internet Explorer Control + B is for bookmarking pages), then the assignment will overwrite the browser functionality.

The Last plugin that I’ve completed is one called “TextZoom” that, like its name implies, lets the user enlarge the text on the page. When the admin enables this plugin, they also can specify Access Keys for the enlargement functions. There is five levels of enlargement: default, small, medium, large, and extra large. When a user selects any of the enlargement levels, the settings are automatically remembered for 30-days using a cookie, so when they visit the site again, the text will automatically be enlarged for them. The user can then press the default option to go back to the default site and remove the cookie from their browser.

There are other plugins that I’m working on, including a Google Analytics plugin that will let an administrator look at current website tracking information right from within the admin pages.

Where Can You Get The Plugins?
I have the three plugins mention in detail above available for download at BrailleSC.org/development. I also have the source listed on my own development wiki at CoryBohon.com/development. The plugins are completely open source, so if you wish to take the source code an improve it you can under the terms of the included GNU public license.

If you have any questions about the plugins, you can email me directly at cory [at] corybohon [dot] com or cory [at] braillesc [dot] org.

As many of you may know, I’ve been doing some programming on the side (and part of my course work at my university). From programming in Java to PHP, I’ve written a good number of applications over the past few years, and I’ve decided to open all of those apps up.

If you go to my Development Wiki, you’ll find a list of the programming languages that I currently have source code listed for. When you click on those, you’ll be able to see individual projects that you can then look at the source code for, and in some instances, download the source code in a nice .zip format.

Most of this code has been sitting around on my MacBook Pro for the last year or so without being useful, so I figured that I would put it to good use. If you’re a C.S. student, or just someone looking to learn more about programming, check out the Development Wiki. I also have plans for a Java programming screencast/blog that will allow others to learn how to program in an easy way.

If you are at all interested in the Java programming tutorials, feel free to leave a comment and let me know your level of computer experience and if you’ve programmed before. I would really like to see more people learning how to program as technology is and will be a key involvement in the future.