A poll and an update

First off, I have posted a poll in the right-hand column of the blog asking for feedback from users about the storage of nicknames in the Chrome extension. I'm trying to gauge the importance of the feature as it is a development burden to try to support across implementations, so please vote as this will help drive whether nickname storage becomes more pervasive or goes away.

Second, I just wanted to give people a general update of why everything has been so quiet and where I see things going in the future. I finished my Ph.D. earlier this year and now I am preparing to move and start a new job next month. Because of this I don't expect to have much development time for Oplop personally in the immediate future, but I have not left the project! It helps that I'm a user too, and thus I want to see new features come in at some point. =)

Third, I have some thoughts bouncing in my head on where I want to take Oplop overall. Using Firefox 4 a lot more has made me want to tweak the CLI implementation so that it can take an optional flag specifying that you want to validate your master password. I also now own an iPad which makes me want to support a tablet format better, if not develop an iOS app with integrated clipboard support.

But the one thing I have not decided about is nickname storage. Having the Chrome extension be the only implementation that stores nicknames has begun to irritate me as I don't have access under Firefox or on my iPad which I have been using more recently. This has led me to think about whether I want to expand the nickname storage so that it is used in more implementations or actually cut the feature out in order to simplify development and unify the implementations more. And me being me, I do not want to do a partial implementation of nickname storage, which means some cloud synchronization that the last poll showed a large minority of folks are not comfortable with. This means I am leaning towards removing nickname storage from the Chrome extension and instead suggesting to people how they can store their nicknames securely if desired, but I am open to being swayed if the poll suggests that would be a bad move. At worst I could simply leave the feature in just for the Chrome extension if push came to shove.

The big thing I want to do is simplify the development by moving off of Google Closure and back to jQuery (it would simplify the structure of the project immensely) and then unify around a single HTML/CSS UI that is as widely shared as possible. That way the only changes required to deploy a new implementation is packaging it up and optionally adding support for the clipboard. Once again, with the Chrome extension being as special as it is, aiming for this unification becomes harder the more customization that is supported by different implementations. This is why I hope people answer the poll to help me figure out how important the nickname storage is to people.


Tips and tricks for using Oplop

Having used Oplop since I created it back in 2007, there are a couple of tricks I have picked up that makes its use easier that I figured I would share. Luckily Oplop itself is simple enough that I don't have that many tips. =)

My first tip is to choose a very consistent way of coming up with an account nickname. Some people simply use the domain name in all lowercase. Others use the domain name minus the TLD in lowercase. Others use the title of the website. Regardless of what technique you use you should make it is consistently used, quick to use, and especially easy to use. Don't rely on nickname storage; that's for convenience that those random times you just happen to forget your nicknames, not to act as the primary way that you do remember your nicknames.

My second tip is for password requirements that Oplop's created account password simply does not meet. Typically this stems from a password requirement like having two digits to a number or some non-alphanumeric character. In these situations I prepend a consistent thing to meet the requirement. So for digits I prepend a "1". For non-numeric strings it can be "#" or "!". Much like with nicknames, the trick is to make it consistent so you can remember what you change.

And that's actually it =) . Someday I may add support to the Chrome extension to store what to prepend to an account password, but since it is not impacting me at the moment I don't feel compelled to prioritize that feature above others.

User survey results: answering people's questions

At the end of the user survey, I left an open-ended question to let people provide feedback, ask questions, etc.

First off, thanks to everyone said they appreciated Oplop! This project started out as something I did for my own needs and figured a couple of people might appreciate. I never imagined it would reach the point where I have 88 users of a Chrome extension of mine and 34 users of a Chrome app, let alone the Python implementation being downloaded 185 times!

With that out of the way, let's have a look at the questions I received in the survey.

User survey results: what should the next implementation of Oplop be?

In the first Oplop user survey I asked users what they would want the next implementation of Oplop to be.

A native Android app came in at 9 votes (out of 18). A Firefox Jetpack extension came in with 2 votes, both the Safari extension and Mozilla Open Web App ideas got a vote a piece, and a native iOS (which would cost $5 or something to cover the $100 cost of registering with Apple's App Store) got no votes. The "Other" votes were three blanks, someone who simply stated they were content, and someone asking for a long press solution (which at least on Android is not doable as there is no password intent that I could find).

To me this says that the basics are covered in terms of what implementations are already available, but a majority of users would like to have a native Android implementation.

Oh, and hardly anyone wants specific support to print out their nicknames.

User survey results: back up nicknames to the cloud?

As part of the first Oplop user survey, I asked a question to gauge how comfortable people would be in backing up their nicknames in the cloud (i.e., at oplop.mobi). The main driver of this question was for me to see how far users would be willing to go to sync nicknames from the Chrome extension to a (currently mythical) native Android implementation of Oplop. The available answers to the question were:

  • I don't want anyone but me to know my nicknames; touch the network and I won't trust you! I don't like storing them in any fashion. (2 votes)
  • Just let me shuttle them around out-of-band (e.g., by file, scanning a QR Code, etc.). (2 votes)
  • I don't want them stored in the cloud, but you could keep track of the last edit so I know if the copy of the nicknames on a device is stale so I can copy them out-of-band. (1 vote)
  • I don't want you storing them, but I trust Dropbox to store them so grab them from there. (2 votes)
  • If you use strong encryption (e.g., AES-192), I would be okay if you stored my nicknames on my behalf. (10 votes)

Let's have a look at what each answer means. "I don't want anyone but me to know my nicknames" means what is sounds like: no cloud support. I suspect people who chose this answer are the type who run the Chrome extension from a source checkout to have complete control over the code as a way to audit it. They are also the type to use the CLI over any web- or browser-based implementation of Oplop as the Python implementation is very easy to understand if you know how to program (which I suspect a good portion of Oplop's user base do). In other words, these people probably don't store nicknames in the first place (which is fine; I have already decided to not have the website or Chrome app ever store nicknames for people like this, although I might let the Chrome app access nicknames stored by the Chrome extension someday).

"Just let me shuttle them around out-of-band" was the answer for anyone who was happy to have nicknames stored in their browser, but didn't want anything going out over the network. So what I could do in this situation is generate a QR Code in the extension for people to scan with their Android phone to get nicknames from one to the other. Another option would be to allow someone to copy their nicknames file to/from their computer to their phone. The point is everything would be done out-of-band (i.e., not done through a network of any kind).

"[Keeping] track of the last edit so I know if the copy of the nicknames on a device is stale" was to allow oplop.mobi to store for people when an edit last occurred of their nicknames to act as a reminder that they need to copy their nicknames to a device. For instance, if I edited my nicknames in the Chrome extension it would send a little message to oplop.mobi that I lasted edited my nicknames today. When I launched the Android app it would ask oplop.mobi when the last time I edited my nicknames were. Noticing that the last time of edit was newer than the last time nicknames were copied to the phone I could receive a notification that I should probably update the copy of my nicknames on my phone.

"I trust Dropbox" is for the situation where one stores their nickname file in Dropbox (and if you don't already use the service, you should; if you sign up using the link I provided I get 500 MB more storage =). Thanks to the Dropbox API for mobile devices I could have it set up so that the Android app pulls a nickname file from a pre-determined location so that you just have to make sure Dropbox always has the latest copy of the file. This doesn't help synchronize nicknames between Chrome browsers, but it does take out the manual steps for keeping your phone synchronized.

"I would be okay if you stored my nicknames" means what it says: oplop.mobi backs everything up securely and in a way that I can't view the data. I would most likely encrypt the nicknames on the client side using your master password and some label like "Oplop nicknames" or something, store them on oplop.mobi, and then send them to any device that had outdated nicknames. Since it's encrypted only you could decrypt them; I would not be able to figure out what your master password was or all of your nicknames w/o spending probably millions or billions of dollars on compute time and who knows how many months to years of time even with that amount of money.

With all of this in mind, what do these voting results mean? With 18 voters, the "store nicknames" vote gets a majority, but that's not enough to warrant necessarily scaring off users because the Chrome extension and Android app suddenly need network access. So the real question becomes where the 80/20 rule kicks in. 15/18 is a little over 83%, so that means the only level of communication that 80% or more of Oplop users are comfortable with is out-of-band (i.e., no network communication). Assuming that there are no major issues generating QR Codes large enough to contain someone's nicknames this should work fine (I would use Google Chart Tools but that requires sending data to Google which some people might not be comfortable with), albeit with a slight pain in synchronizing nicknames.

User survey results: what implementation(s) are used the most?

The first question I asked on the user survey (as answered by 18 people) was what implementation(s) of Oplop did use? The results were a little unexpected.

The Oplop web app is the most used implementation of Oplop at 13 out of 18 responses. Next comes the Chrome extension at 11, following by the CLI at 8, and Android with 5 (the rest were below 20% of users).

I must admit I expected the Chrome extension to be at #1, followed by the website. I definitely didn't expect the CLI to come in at #3.

But my surprises didn't stop at the ordering of the implementations. If you look at which browser people are using to access the website, that is even more of a shocker.

Chrome comes in at 11, Firefox, at 6, and Android at 4. I can understand Firefox as there is no Firefox-specific implementation of Oplop. But Chrome has both the extension and the app. The former (hopefully) gives you a nicer, more integrated user experience compared to the website. And the latter is literally the website packaged up in a zip file so that you can have Oplop available as a nice app icon in Chrome!

So that makes me wonder why people are still choosing the website over the extension or app in Chrome. With Chrome apps being such a new thing I can understand that leading to people not transitioning from the website to the app. But the extension has been around for several months now. Is it a worry about security? It is rather unfortunate that the extension does require that it have access to "your data on all websites" and "Your browsing history". The former permission is needed to discover if there are password field(s) in the website and to subsequently put your account password into those field(s). The latter permission is so the extension knows what tab you have open so as to not put an account password into the wrong tab. There is no network communication anywhere, so people shouldn't have to worry about that (if there was it would be another permission). Or maybe people just really dislike the workflow I have gone with in the extension? If you happen to use the website over the Chrome extension, please leave a comment as to why.

As for using the website over the SL4A script, I can understand that from a installation complexity point-of-view. If you don't want to install an app outside of the Android Market I can see how having SL4A as a requirement might put some people off. And since Android 2.1 and later support offline web applications then you still have Oplop available when you have a spotty internet connection on your phone.

So, what did I learn? People like the Chrome extension and the website; no surprise there as they provide the most integrated and most fundamental experience of Oplop, respectively. But knowing that most people use the website on Chrome on any other browser makes me wonder why they do so over the extension or app for Chrome (as I stated earlier, if you do this yourself please leave a comment to let me know why). Also knowing that a good chunk of people use the CLI has me considering upping the priority on issue 28 (you can always star issues on Google Code as a way to vote for it to be worked on).


New blog for publishing updates

As a result of the first Oplop user survey, this blog has been created to host announcements for anything related to Oplop. Posts will mostly be release announcements, but will also involve discussion about the project and potential future directions (including the results of the user survey). Please subscribe to make sure you are always able to stay on top of developments related to Oplop!