An Open Discussion About the Future of Clippy

An Open Discussion About the Future of Clippy

I just got another email about Clippy, from the same person [Tony] who was having trouble using it earlier due to the force close issue, and they mentioned some interesting ideas that I discussed with them via email, and I wanted to share these ideas with the rest of the readers on my blog (There are people who actually read this, right?).  So anyways, they wrote to me asking what the purpose of Clippy was, and pointed out that there is a significant lack of information about it, and I have to agree that they’re completely right. There’s barely any information about Clippy at all, even on my blog, where I posted several lengthy posts about the project. Part of that can be attributed to the fact that Google only lets you have a 325 Character description about your project, which has been quite a hassle for me on numerous occasions, since I like to write long descriptions about my project, but that’s not the only reason that Clippy seems so vague and mysterious. Truthfully, the primary reason for that is because, well, it is. Clippy is currently in an extremely early stage of development. I haven’t even been working on it for a solid week yet. The reason I’m releasing a public beta even though I realize that there is still a lot of work to do before Clippy reaches a point where I feel comfortable shipping a final, stable version is because I feel that I should let the users develop it. Not literally, where the users would be whipping out Eclipse and writing Java code, but rather on a user interface level. I believe that by offering a chance to test Clippy far before it’s ready to be released, I’ll be getting better feedback than I would if I finished the whole thing without any external input, and shipped it to the masses. I believe that the best kind of feedback is that of someone who uses the application frequently in their daily lives. Clippy isn’t just written for one specific purpose. It is a tool that can be adapted to several different needs, and as I try to meet the needs of those who use my application, it will become more robust and flexible to the demands of users. As I read Tony’s email, I realized that I have no idea what I’m doing when it comes to creating a product to meet the needs of those who use it, as I haven’t used something similar before. The truth is, if anyone knows what could make Clippy a better product, it would be the actual users, not the programmer. While reading that email, I recognized several shortcomings of my application, and realized that the best way to approach the future of the application is with the guidance of the ones using it. Therefore, I take all feedback I receive very seriously, even if it’s negative, as I want to offer options to meet everyone’s needs to the best of my abilities, and I want to do so without causing problems such as crashes (force closes), or sluggish performance. Reading Tony’s letter made me recognize several things I didn’t realize before. For example, it can be annoying to manually archive a clipping when you are making several rapid changes to the clipboard contents. After reading the email I received, I thought about all of the points mentioned, and considered all the possible implications of implementing their ideas, and I wanted to share my thoughts about each one of the points mentioned in Tony’s email with the readers of my blog, as some of my decisions about these ideas greatly reflect the direction I want to go with Clippy. Anyways, here is what they wrote to me (omitting personal details):

That seems to have solved the problem, Dylan, thanks!

There’s a bit of a lack of information about Clippy. Does it watch the
clipboard and cache clips as they’re made? That’s what I hope it does
— I use ClipStore now and it’s far from perfect but better than
nothing. I like having a list of the items that have been on my
clipboard so I can go back to them whenever necessary.

I’d also like to suggest that you provide the ability for it to reside
in the Notification bar for quick access and also provide a widget,
perhaps showing the last n items (configurable) so I can select
previous clipboard items and have them put back on the clipboard.

Nice job! Keep it up!

In this blog post, I address each of the issues mentioned, break them down into pieces, and discuss my thoughts about how I could implement them.

There’s a bit of a lack of information about Clippy. Does it watch the
clipboard and cache clips as they’re made? That’s what I hope it does
— I use ClipStore now and it’s far from perfect but better than
nothing. I like having a list of the items that have been on my
clipboard so I can go back to them whenever necessary.

As Clippy is right now, it does not watch the clipboard as it’s modified, for that, I would need to add a “service“, and have it running in the background monitoring the clipboard contents, but I will admit that automatically monitoring the clipboard and archiving any changed versions of the clipboard is a great idea that I will consider implementing in the future. Right now, you have to manually archive clippings by clicking the archive button in the “Current” tab, and entering a title for the clipping, which isn’t ideal, but the user interface will likely, if not definitely, change significantly before the final release. For instance, I plan on adding a settings menu, and several other useful features. The reason I have the user enter a title for a clipping is because I figured that if you use this tool frequently, you’re going to have a lot of clippings to manage, and having them sorted by an expandable title really makes it easier to find what you’re looking for. Especially since clippings tend to be very long sometimes, and scrolling through the list and trying to find the one you want can be a hassle. On the topic of sorting, I was planning on allowing the user to change how the clippings are sorted, for example:

  • By time added, ascending
  • By time added, descending
  • By clipping title, ascending
  • By clipping title, descending
  • By clipping length, ascending
  • By clipping length, descending

I already have “id”s and “timestamps” automatically generated and stored in the database when a clipping is archived, but as it currently is, I do not currently store the clipping length in characters/words, so I would most likely need to do a database update to add that functionality. Unfortunately, this would likely mean that users would lose their clippings, so I’m currently trying my best to avoid changing the database structure unless it’s absolutely necessary, but it’s almost inevitable that I’ll need to modify the layout of the database before I release the final stable version of Clippy. However, in this case, it’s possible to calculate the number of characters and words in each clipping “On The Fly“, but that would result in a delay every time the list of clippings changed, such as when they user deletes a clipping, and the list has to be reloaded. The effect wouldn’t be that noticeable with a small amount of clippings, but with a larger database, the amount of the delay could increase significantly, as it would multiply based on the number of clippings the user has. Depending on the number of computations I do “On The Fly”, the amount of the delays could add up, resulting in a sluggish user interface, and a bad user experience, where as if I stored the pre-computed values in the database, there would be no need to re-compute this data every time the list loads, as it would only need to be done upon modifying the clipping. It would also save battery life, due to the reduction in CPU usage, but the amount of battery life wouldn’t be that significant, unless the user had many clippings stored. There are quite a few things I’d like to store in the database alongside each clipping, including:

  • Character Count
  • Word Count
  • Creation Time (Already Stored)
  • Time of Last Modification

I’m sure there’s a lot of other metadata that’s worth storing, but these are just off the top of my head. Back to the topic of automatically archiving clippings, the biggest obstacles to having it automatically archive changed clipboard contents at the moment are more along the lines of design decisions rather than any actual programming limitations. There’s a plethora of things which I need to take into consideration when writing a background service to have Clippy automatically archive clippings, and even the slightest differences can make a huge impact on the overall user experience. Therefore, it’s important that, if I implement that feature, I take extra precautions to ensure that the user has a positive experience with the feature. I’m going to take the time to mention several things I need to consider, and possible implementations. These are all still at the idea phase, so nothing here is guaranteed to make it into the final product, and everything is subject to change, but I still feel that it would benefit not only the users of my application, but myself as well, since letting you guys know how I plan to change Clippy will hopefully generate lots of valuable feedback that I can base critical design decisions off of. Here is a list of several of my concerns about adding a background service to automatically monitor the clipboard, as well as several ideas I have as to how I’m going to deal with them:

  • It needs to be easy to turn the feature on and off. If the user can’t quickly disable/enable the feature, they won’t want to use it.
  • There are certain things that might end up in the clipboard that the user does not want to be automatically recorded, such as personal information, passwords, random unwanted text clippings. I’m sure you can think of a few examples. If a user lost their device, or they were unaware that it was still recording data, it could lead to unfortunate complications. Also, it would be troublesome for the user to go through their list of clippings and remove all of the unwanted clippings that they accidentally added
  • Assuming the user forgot to turn the feature off, it is very possible that the clipboard can change very frequently. Having every single change to the clipboard recorded uses up a lot of space on the device that could be better used for other purposes. This could lead to the user having to manually remove all of their accidental clippings, or getting frustrated and removing the application altogether. One possible solution to this is to allow the user to choose to store the database on an external SD card (a feature I was thinking about adding anyways), but still, I think there definitely needs to be some kind of visual cue in the notification bar that Clippy is currently running and automatically archiving every single change to the clipboard. Perhaps even accompanied with audible or haptic feedback (slight, short vibration) every time Clippy adds a clipping to the database (of course the audible feedback would have to respect the user’s choice of whether or not their phone is in silent mode). Another good idea is to send a notification to the user after extended periods of the service running, through the notification bar, saying something along the lines of “Clippy is running.” (it would have to be short and concise to fit in the notification bar).
  • When clippings are automatically added, what should the new clippings automatically be titled? (I was thinking along the lines of having them automatically titled by date and time, for example “08/04/2010 8:35:47 PM, EST”, but that makes finding the exact clipping you want difficult and tiresome. I could always have the user be prompted to either enter a title for a new clipping every time the clipboard changes, and offer them the option to choose not to save the clipping. That would prevent clippings from accidentally being saved, and it would take care of the naming issue. Another idea I had would be to have the user enter a “Session name” when they start automatically recording changes, and have that prepended onto the date/time. However, that would result in a really long title, which might end up getting wrapped off the edge of the screen… or maybe it won’t… I’ll look into that, however, I believe that it would result in a bunch of similarly named, unsightly titles. Another option is to let the user select the format for automatically saved clippings, from the solutions I mentioned here, but that could end up cluttering the settings menu, and determining what to name the settings so as to not confuse the users would be difficult. Perhaps those settings could go in a sub-menu.
  • When the device becomes inactive and goes to the lock screen, the service would need to automatically pause, and resume when the device becomes active again. There is probably a way to do this using the built-in functions of the Android API, or for all I know, Android handles that mostly automatically, and I just have to check if the device is locked or not.
  • How often should the service check for clipboard changes? In order to automatically save clipboard changes, the service would need to “poll” the clipboard to check if there is anything in the clipboard, and if there is, it would be compared to the last archived clipboard entry. The problem is, how often should the service check for changes? If the period between checks is short, the clipboard contents would be archived quickly, and accurately, almost as soon as a change to the clipboard is detected. However, this comes at a cost of battery life and CPU usage. However, if I have a long period of time between the clipboard checks, the program might miss a change completely. Therefore, I believe a good compromise is to either have the user set the polling rate, or allow the user to have the program automatically adjust the amount of time until it checks for the next change, depending on the average amount of time between clipboard changes. However, even this solution isn’t perfect. There are often times when the user is frequently changing the clipboard contents, and it would be a major annoyance to find out that only 3 of the 8 changes they made were recorded, but at the same time, users often have the phone in their pockets, not doing anything, and when that happens, it adds an outlier to the data used to calculate the average time between clipboard changes. Therefore, it becomes necessary to force the time between checks to be within a predefined range, most likely configured by the user, so that if there is a long time between clipboard changes, it won’t offset the data enough to cause the service to miss a clipboard change. I believe that the best way to do this is to detect long periods of complete inactivity (absolutely no interaction with the device at all), and not adjust the rate which the service checks for changes during that time, assuming the user never paused or deactivated the service. Also, because the amount of time between clipboard changes varies not just between users, but also between usage sessions, I think the average time between a change in the clipboard should automatically be reset to a median value after long periods of inactivity, as the user could be working on a completely different task than before they stopped using their device last.

Anyways, that’s about all I can think of for possible problems related to automatically saving clippings. Another interesting idea that they brought up was me making a Clippy widget:

I’d also like to suggest that you provide the ability for it to reside
in the Notification bar for quick access and also provide a widget,
perhaps showing the last n items (configurable) so I can select
previous clipboard items and have them put back on the clipboard.

Making a widget isn’t a bad idea at all, in fact, it’s a great idea, but I don’t have any experience making widgets, and I’ll have to learn how to do that, however, I could always give it a try. That could be a very useful way for users to interact with the program and it could even have shortcut buttons to start/stop the automatic recording of clipboard changes. Hmm… perhaps I could have the widget only included with a “Pro” version of Clippy, since only offering a version without advertisements isn’t very appealing to users (based on my experience selling FiOS WEP Calc). There needs to be some sort of perceived value in order for anyone to want to purchase it. Especially when they can get all of the functionality offered by the full version for free. Regularly I wouldn’t have a problem with offering a free version that’s supported by advertisements, but AdMob barely makes me any money (It’s not even at a dollar a week yet), even though my project has over 500 unique downloads, and over 350 active users. 😦 Clippy is currently in a very early stage of development, so now is a great time to make major changes in the way it works, since it isn’t a very good idea to make huge changes after shipping a stable version. I will most likely include all the features that will ship with the “Pro” version in the public beta, but I don’t know if I will leave them in the Lite version. That mostly depends on how many sales I get on my other applications, and how much advertising revenue I make. If anybody reading this has any more great ideas, or if you find any other bugs, even if they’re trivial, and you feel they’re unimportant, let me know so that I can look into it. 🙂


One Response to An Open Discussion About the Future of Clippy

  1. Pingback: A Brief Update on Clippy « Dylan Taylor's Personal Blog

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: