Category: Kev’s Blog

Posted on

Windows 10 Users “34 per cent more likely to be strongly satisfied with the filtered Taskbar”

Let that statement sink in for a minute – in Windows 10 Insider Preview builds, users have indicated they are:

"34 per cent more likely to be strongly satisfied with the filtered Taskbar"

… and based on that not-so-convincing statistic it’s been decided that the taskbar for a virtual desktop will only show apps running on that desktop (presumably hiding others that are running on other desktops at the time time?).

Gabe Aul at Microsoft describes in this post the latest features in the Windows 10 preview build and how feedback from preview build users is helping Microsoft decide what new features will make it into Windows 10, and which won’t.

And there you have it. Apparently the design of the Ribbon Bar in the latest Office versions was also designed the same way, based on observed/recorded usage patterns of ‘actual users’. If you think the Ribbon Bar is actually a good design then I won’t waste my time arguing with you, but most would probably agree from a usability point of view it’s a horribly cluttered, confused mess of somewhat related options. The Ribbon Bar reminds me of a set of cluttered drawers that are where you stuff your junk that you don’t have anywhere better to put. Each drawer has vaguely related things in it, but good luck trying to find something specific – you open a drawer and spend 10 minutes digging around in there trying to find what you’re looking for. Similarly for the Ribbon Bar – good luck finding that one specific feature.

So at some point if your’re lucky enough (?) to have Windows 10, you might wonder exactly how Microsoft arrived at a decision for why a certain feature is a certain way. And you can be assured that it was designed that way because 34% of preview build users (by a long way as far from a typical user as you can get) decided they were ‘most likely to be strongly satisfied’ if it was that way.

Posted on

Sometimes the simplest solutions are the best solutions

How many times have you seen or written code like this (in any language):

[code]
if(someFlag){
someFlag = false;
}
else{
someFlag = true;
}
[/code]

I’ve written code myself like this many times, and seen it in many places too. Usually for toggling display of some content: “if it’s hidden, show it; otherwise, hide it”.

Recently I’ve been spending a lot of time learning and coding an app using AngularJS and I keep seeing this pattern repeatedly in many code examples:

[code]

someFlag = !someFlag;

[/code]

When I first saw a statement like this it took me a couple of seconds to understand the purpose, but then when it clicked I laughed out loud in one of those ‘ahah!’ moments, as the outcome of this code is exactly the same as the code above.

When we translate design to code, sometimes thinking in logical, procedural steps hurts the ability to translate to code that best uses the features of the language or platform that you are running on. Sometimes the simplest solutions really are the best solutions, although maybe it takes a different thought process to get there.

Posted on

Choosing an Issue Tracker for an Online Service

I’ve been working on an application that I’m getting close to publicly launching, and while the site is mostly functional with most of the development done (I’ve been working on it in my ‘spare time’ for almost a year), there’s some non-development tasks I need to complete before launching, including:

  • adding Google AdSense and Analytics
  • completing online documentation
  • setting up an online issue tracker

The options for an issue tracker has taken me by surprise as there are so many options, ranging from free to varying monthly fee options. I’m somewhat familiar with some of the older free development project focused options, like Bugzilla, Trac, Redmine, and commercial options like Atlassian’s Jira. Part of my app is open source on GitHub and so to use the GitHub issue tracker for that part is an easy choice. I’d also like to make sure whichever issue tracker I chose is easy to use from the point of view of my end users, the majority of which are unlikely to have existing GitHub accounts, or accounts on other online tracker sites, and I want to make sure it’s as easy as possible for them to log issues and enhancement requests.

(This article here has a good list of a number of issue trackers.)

Ranging from simplest to use, Trello is a stand-out from the crowd. Although it’s not a dedicated issue tracker, the approach of managing lists of items and moving items (cards) from one list (e.g. open items) to another (e.g.closed items) is trivial.

Categorized in interesting-but-with-high-technical-requirements is YouTrack from JetBrains, and free for upto 10 users … but requiring 1GB heap to run, this would cost me some monthly runtime costs for  medium gear on OpenShift, so I’m not sure  if this is worth the investment at this point.

Next up in the looks-interesting category is Asana – I’m not familiar with this service, it looks like it offers much more than I would need, but could be worth investigating.

I’ve some decisions to make here, and right now I’m thinking either using GitHub’s issue tracker or Trello. What would you recommend – leave me a comment!

Proudly powered by WordPress