MRR Software

There was much ado on Twitter today that warnings within an application are, at best, passé.  It has come to pass that many developers feel warnings have become so ubiquitous that users no longer read them, regardless of content.  I was nearly alone in my conviction that warnings not only have a place, but can be necessary within an application.  Apple’s Human Interface Guidelines suggest: “Warn users when they initiate a task that will cause irreversible loss of data.”  I’ve taken that thought a littler further.  My ardent belief is that a user should always receive a warning dialog if the following three criterion are met:

1. Data is lost
2. It takes non-neglible time to manually recreate the lost data
3. The lost data will affect future runs of the application

All of these criteria deal with data.  Nearly all applications exist solely to process and store data.  When a user enters data into an application it, and by extension the developer, becomes the guardian of that data.  It is up to the developer to ensure that the data is safe, that we keep it from harm.  And the same time the user must be allowed to create, destroy and modify their data as they choose.  Every operation that a user performs on their data involves a certain amount of risk.  Here risk will be defined as a situation invloving exposing the user’s data to danger.  Most interactions have very low risk, including creation, modification and viewing of data.  Conveniently these are the most common types of interaction with data.

Deletion is the odd man out, for all his low risk brethren, deletion has significant risk.  It is the complete loss of data.  Some applications will allow deletions to be undone, a very effective catch all for accidents, or for rectifying a misunderstanding between user and application.  But the ability to undo a mistake is not a replacement for preventing it to begin with.  An ounce of prevention is worth a pound of cure.

Many have suggested that Undo is a magic cure-all for deletion, this is a fallacy.  Undo is only good until the program exits.  In the case of accidental deletion, where the warning dialog truly shines, the user will not know they need to undo it.  Maybe they thought a different window had focus, maybe they fumbled a keyboard shortcut, or maybe their cat had a nap on the delete key, doesn’t matter.  Once that application is quit, that undo memory is gone, as is the user’s data.  At this point Time Machine or backups (either user or program initiated) are the last hope.  If any part of your application’s workflow relies on the fact that there should bebackups, you have failed.  This is why my second criteria states that it takes non-neglible time to manually recreate the data.  Don’t rely on backups and undo.

It is important to realize that not every deletion require warning, as not every deletion has the same level of risk.  I have adopted both approaches in my applications.  NameChanger’s toolbar prominently displays Remove and Clear buttons.  Remove deletes the selected filenames from the table and Clear removes all entries from the table.  Neither of these deletion operations spawn a warning.  Isn’t data being lost, why not warn the user?  Let’s see how it matches up to my criteria.  First there is no true loss of data, a filename is removed from a table, nothing more.  Second it would take longer to warn the user then for the user to manually re-enter the data.  Thirdly, nothing is persisted between runs, so quitting after removing a filename has no impact on future runs.  The data, in this case a filename, is only a short file browse away.  The risk is not great enough to warrant an interruption of the user’s workflow.

Now the other case: the next release of Syrinx will contain a List management window.  A Twitter list is a user-defined set of Twitter friends.  A user can have multiple lists each containing up to 500 members each.  When attempting to delete a list Syrinx presents the user with a warning.  Why give a warning?  Back to the criteria.  First actual data is being lost, those lists and members are deleted from Twitter’s servers.  Second, it can take a significant amount of time to recreate the list and it’s contents, assuming the user can remember it all.  Third, since the data is persisted, the deletion affects future runs of the application.

I challenge developers to apply these criteria to their own applications to determine when and where warning dialogs are appropriate.  Don’t jump on a UI bandwagon just because it’s rolling through, determine what is right for your application.

There is a constant balancing act going on for Syrinx development.  I get plenty of great suggestions from users who have thought of things they would like Syrinx to do.  On the other side Twitter is not a static platform, it is growing all the time.  Just in the last few months they have added spamming, lists and retweets.  Both of which require a significant time investment to integrate into Syrinx.  So a balance has to be struck: features vs requests.

I tend to swing between theses two ideas, one release focusing more on small requests and UI tweaks, then back to adding another Twitter feature (be it old or new).  This next release will include retweets, since currently folks are missing out on tweets that are retweeted using the new API.  I would have liked to include lists as well, but that will require some more thought and time on my part and I want to get the retweeting functionality out to everyone.

I also get bug reports.  These are very important, they are what keep Syrinx healthy amidst feature and request expansion.  There are a lot of moving parts under the hood compounded by more moving parts in the UI, so all in all I’m bound to miss some bugs, especially in uncommon situations.  Beyond the easily reproduced and fixed bugs are the quiet reclusive bugs that I cannot myself reproduce.  One of the major problems with having a client that integrates with an online service like Twitter is that everyone’s timeline is unique.  That means every instance of Syrinx out in the wild is encountering different inputs.  When one out of a thousand users encounters a problem, it is all but impossible to reproduce on my end unless I hit that same condition.

All of these things fit into an equation which is dominated by my amount of free time.  As home and work get  more busy and require more time, Syrinx gets less time.  Sometimes all of these factors meet and collide and Syrinx has to limp along missing functionality.  This also leaves my other project, NameChanger, on the backburner.  Since Syrinx is aiming at a moving target (Twitter), it demands more attention, even if I have lots of great ideas for NameChanger.

A new version of Syrinx, supporting the reading and sending of Retweets will be out soon as the march toward feature completion continues.  Your patience is appreciated as Syrinx and I catch back up.

The 5 stages of grief, or the Kübler-Ross model, was introduced in 1969 as a description of how people cope with grief and tragedy.  It occurred to me that programmers experience a similar set of stages every time they encounter a bug in their software.

1) Denial – The stage that launched a thousand “Works for me” emails.  After all, your code couldn’t produce that bug, it was flawless and you tested it.  Or you thought about testing it, which is just as effective.

2) Anger – Providing a smooth transition from denial you begin blaming everything and everyone around you, and vague compiler errors only fan the flames.  This stage is easy to spot, just listen for someone cursing out the compiler for telling the truth.

3) Confusion – Once you’ve calmed down and made your peace with the compiler, it’s time to realize you have no idea where the bug is or how to reproduce it.  This is a good time to muss your hair and start muttering to yourself.

4) Depression – This one is optional, but if you start daydreaming about a different job or questioning the overall architecture of your application you’re in for a stay at stage 4.

5) Acceptance – This often occurs when you at last can repeatably reproduce the bug and have tracked it down to a line of code.  It’s been a fun journey, but you’re ready to fix it and move on.  This isn’t the time to reflect on the mistakes made in other stages, you’ve just made your software better!  It’s best to close this bug out and move on to the next one.

After what seems like an eternity, Syrinx 2.0 has emerged from beta and is available to all.  It’s been out for a little over 24 hours now and the response has been great.  Lots of good feedback is going through the Twitter timeline.

Many thanks are due to the many people who beta tested 2.0 and sent in bugs and feedback.  This major release could not have been successful without all your help and support.

For this release I did something new: a Press Release via prmac.com.  I’m interested to see what impact that has on the amount of exposure Syrinx receives.  So far it seems like it has spread quite well.  Now if I can catch a review or two in some well read Mac websites we’ll be on our way.

Looking forward I think the new timeline architecture is really going to give me a strong base moving forward.  I have lots of ideas I would like to implement and users have sent me even more ideas.  I’m excited to see where Syrinx grows from here.  When I first published Syrinx it was one of only a few native Twitter clients available for the Mac.  Now we’re inundated with clients, each more polished than the last.  So far I think Syrinx’s unique feature set, especially Pause and Bookmark are really keeping it a little separated from the rest of the clients.

I’m also looking forward to exploring the iPhone development platform, and  I’d like to spend some time working on NameChanger.  Also, I’m headed to WWDC this year, it’ll be my first time.

It’s a busy summer ahead, but I look forward to it and producing some more great software.

As many of the beta testers know, Wednesday night (~10:30pm EST), the Syrinx beta would no longer login to Twitter, or more accurately it could no longer call the verify_credentials method from Twitter.

While deploying other fixes, the API folks at Twitter discovered a loophole that some were using to circumvent the Rate Limit.  This involved modifying how the verify_credentials method could be called.  The Syrinx beta, among many other twitter programs were caught completely off guard by this.

Ordinarily the Twitter API team gives reasonable notification before changes occur, but this time they did not and things broke.  There seems to have been a lot of heartburn over this and the Twitter API team has sent out emails claiming that they will work harder in the future to notify developers at least 5 days before public API changes except for necessary security and performance issues.

Compounding the impact of this error, I was at my day job for 12 hours, so Syrinx was crippled for an extended period of time.

It’s all fixed now and hopefully with more transparency from Twitter in the future these types of outages can be avoided.  I’d like to thank everyone for their patience and understanding in this issue.

At last the beta is public!  Here’s a link to the beta page which discusses changes and new features:

http://mrrsoftware.com/MRRSoftware/Syrinx_Beta.html

Please send all feedback to syrinxbeta at mrrsoftware.com

Hope you all enjoy this beta, there has been a lot of hard work put into it.

My original plan was to have a beta posted by now for Syrinx 2.0.  However, due to a death in the family I have been doing a lot of traveling and have not had the time to dedicate to a beta.  When I push out the beta I want to be able to stay on top of the bugs and feedback to make this release of Syrinx the best ever.

To make up for this delay, and to fill my downtime while traveling, I have added in some new features.  Yes, sometimes circumstances require you to unlock your feature lock and push ahead.  I think when everyone sees these extra features they won’t mind the delay, which was unfortunately unavoidable.  Sort of a software release version of lemons to lemonade.

At long last I’ve locked down the feature set of Syrinx 2.0.  From here I have a short list of known issues I need to work through, then it’s on to a beta.

As many of you know, this release was all about the need for speed.  The tweet timeline, friends list and new search timeline are now tables complete with custom cells.  This results in smooth scrolling and fast searching/conversation viewing even with thousands of tweets.  The memory footprint has also been significantly reduced.

Though the main goal was to upgrade the speed and usability of what was already available in Syrinx, I still wanted to add some much requested features to this release.  But eventually every developer has to let go and make a release, so I’ve locked the feature set and am prepping for beta.

Here’s a list of the features new to 2.0:

• Search – Now you can search all of twitter with auto-updating search windows.
• URL Shortening – Highlight a link in the status update area and use this option to shorten the URL using tinyurl.com
• Tweet Deleting – Ability to delete your own tweets
• Retweet – Automatically retweet the selected tweet
• Open Links – Open all the links in the selected tweet from a keyboard shortcut.  Plus the links are opened in the background.

There was a question posted to the last blog entry about 2.0 release schedule and alpha distribution.  The only alphas in use are by myself and Mike from Fruit Stand Software.  Mike helps validate my builds (Xcode delights in forgetting to include my resources) and to help find initial functionality bugs that I would not ordinarily encounter in my usage.  As far as a release schedule I haven’t nailed anything down, but I hope to get these alpha bugs cleared up in the next week.  I will be tweeting and blogging about the 2.0 release as it progresses.

My blog has been eerily quiet of late, always a good sign that I’m hard at work coding.  Syrinx 2.0 promises to be well worth the effort, but it has been a long road.  Gone is the NSCollectionView of Syrinx 1.x, in it’s place is an NSTableView full of custom cells.  This will address the largest usability issue: Syrinx slows down when it gets several hundred or more tweets.  The newest alpha version I have tested with over 1600 tweets and it does not suffer any loss of speed.  Viewing conversations, which I feel really separates Syrinx from the other Twitter apps is also much faster thanks to the table implementation.  Besides speed, the table uses significantly less memory, making Syrinx a better citizen to be running full time on your system.

The UI is also seeing slight changes.  Fewer boxes, a few drop shadows and a more efficient use of screen space to fit more tweets in the window.

And new features: I’ve even found time to put in some new features.  These will include URL shortening, retweeting and full out searching of Twitter.  I’m looking forward to Syrinx 2.0 as being a new foundation to build even better features off, and I have a few in mind that will really enhance the user experience.

For now, back to coding so I can get this out to everyone.