Signup now!

ChiliProject is an open source issue tracking software. It is a fork of Redmine, an extremely popular and well-made tracking application. I know some of us use it at least one of these in our professional lives, and I think it would be great to give back to ChiliProject by hosting a one-day hackathon focused on UX/UI improvements.

Why ChiliProject over Redmine? ChiliProject’s team is more active and takes more contributions from the community, making any work we do more likely to be integrated into a future release. I’ve spoken about the idea with one of the project leads, and they are definitely open to it.

This gives us as enthusiasts and professionals an opportunity to give back to the open source community.

What will we be trying to solve?

ChiliProject definitely improves on Redmine’s UX, but it is still lacking in a few key areas, particularly in the UI. Specifically:

1. Main bar navigation could be streamlined
2. Secondary navigation is very busy
3. Typography could benefit from an overhaul
4. Many key processes need to be evaluated and streamlined, including the new issue process. For most of these, the functionality is there, but the usability needs some help.

Some secondary objectives on the UI side might possibly be to port to Twitter Bootstrap, Skeleton, or some other responsive framework to make the site viewport friendly. This is an ambitious task, though.

Of course, through the process of examining the UX, more objectives will be realized.

When would we do it?

Saturday June 9th, 2012. I will be able to organize a git server and VM for collaborative use, along with a central location for communication.

In a recent discussion about the use of surveys during beta, many of the participants felt that surveys at the end of a task really lost the feelings and emotion that were happening over the course of the action. The question becomes, how do we capture those emotions quickly? How can we get feedback almost instantly after the emotion is felt?

I think Google+ has instituted the most innovative way of capturing user feedback. If you aren’t familiar with it, I highly suggest that you go through the interface and see that they really put an emphasis on the experience. I appreciate it.

I like the thumbs-up/thumbs-down measure for actions and interfaces – it is a quick and dirty way to get an impression from your user. By quick, I mean it is very easy for a user to choose whether they like something or not, and being able to do that easily means (generally) that more people will do it.

The concept has a flaw, though; what if you dislike something because it doesn’t work? Then what? Thumbs down? What does that tell the researchers and developers? It could mean many things – maybe you really don’t like that salmon color. We need a way for users to like, dislike, or expand on their feedback. Here’s my approach:

Very simple – thumbs up and down that everyone is (getting) used to, and a plus button. I think it’s rather obvious what the first two buttons do. The plus should allow the user to expand on why they liked or disliked something, or perhaps, tell you that it didn’t quite work as expected. The form that is presented should be fast and easy to fill out, with context about what was happening when it occurred. It’s kind of like a stack trace for your interface.

These make sense after actions – they also make sense when incorporated into a design. You could use this concept more than once on a page during A/B testing to get even more feedback. I know that I’m definitely giving this concept a shot and incorporating this concept into the code architecture on my next project.

There are many ways to select an element using jQuery. At some point, it usually starts with $(‘#id;) – from there, you have a lot of options, all of which can severely affect the performance of your script.

A common theme amongst new jQuery users (and myself, admittedly) is that you can continue to select the afore-selected element. Here’s an example:

$('#id').click(function() {
     $('#id').fadeOut();
});

A very simple example, but with expensive implications. Grabbing that #id again is pricey. But that only makes sense – making JS transverse the DOM once again to find your element is a costly task. That’s why a lot of developers, at least in some contexts, use “this” to remove that step.

 $('#id').click(function() {
      $(this).fadeOut();
 });
 

Conventional web wisdom says that you’re going to get a performance increase because you’re skipping the DOM traversal step here – and that is correct. But this can be modified yet again:

var id = $('#id');
id.click(function() {
    id.fadeOut();
});

This is caching the selector in the variable “id” – something that gets to the middle territory of coders as they progress through more complex JS tasks. But which of these is the fastest?

I created a jsPerf case for that very reason. With the help of a fellow Stack Overflower, we were able to produce a very interesting test case.

The “this” and cached methods are, predictably, faster – but what is even more surprising is the variance in performance on cached selectors on a per-browser basis. It is pretty much all over the board. But what does this tell us?

This test is a remark about the different JIT compilers per browser, and how they’re unique to each browser (and in some cases, each version). That’s obvious – what isn’t so obvious is the performance difference between the three tests across the different browsers. Something to consider when coding your next webapp!

I had an interesting question in the comments regarding the Datepicker widget I incorporated before.

Here’s the problem:

The problem that I face now is that the Calendar UI always display before and after a selection is made.

This wasn’t the case in the jQuery example.

Anyway, thanks again for your help.

I did notice that when testing the widget out, and a good point is made – why don’t we fade the calendar in and out? This is a pretty simple change to the code. Here it is (explanation inline):

<link type="text/css" href="/css/ui-lightness/jquery-ui-1.8.5.custom.css" rel="Stylesheet" />
<script type="text/javascript"
 src="https://ajax.googleapis.com/ajax/libs/jquery/1.4.2/jquery.min.js"></script>
<script type="text/javascript"
 src="https://ajax.googleapis.com/ajax/libs/jqueryui/1.8.5/jquery-ui.min.js"></script>
<script type="text/javascript">
jQuery.noConflict(); // Necessary!
jQuery(document).ready(function() {
jQuery("#datepicker").hide(); // Hide the datepicker widget

jQuery("#date-input input").focus(function() { // When the input field takes focus, call this function
jQuery("#datepicker").fadeIn('fast'); // Bring it in quick
});

jQuery("#datepicker").datepicker({ // Establish the datepicker
 onSelect: function(dateText, inst) { // 1. When you select something, what should happen?
 jQuery("#date-input input").val(dateText); // 2. Take the selection and put it into the prompt!
 jQuery("#datepicker").fadeOut('fast'); // 3. After the selection, hide the prompt again.
}
});

}); // End Ready
</script>

This, in its ugliest form, achieves the fade in and out on the prompt. Stay tuned for an optimization to the post using caching to speed up the process a little bit, and make it a little more maintainable.

Here’s a question I posed for discussion on COGNOISE:

Since I’m so new to Cognos, I haven’t experienced an upgrade where everything breaks because IBM decides to change how they render prompts or something.

As a matter of fact, I have no way of knowing if any of the jQuery stuff I’ve been writing will translate to 10, because frankly, we use none of it at my job. I think I have a pretty solid strategy, though.

If I had to guess, I think that the problem is with Javascript breaking because of code like warping – the ID or class is changed, then everything breaks. I’ve countered this by wrapping pretty much all of the elements I’d like to manipulate in HTML items and giving it a div with an ID. I’m pretty sure that isn’t going to change through an upgrade, as I’m writing static code, not the rendering engine.

I’m also selecting by element and position, which may create a problem. Unlike Javascript without a framework, because most of the operations are one line only in jQuery, finding and resolving issues should be easy even in my absence. For example:

jQuery("#YOURIDHERE option:first").remove();

This code for removing an option is one line and pretty much self-explanatory. Go to the ID, and find the first option in that prompt. It’s hard to see a scenario where this would change drastically during an upgrade.

So that’s what I’m asking! There’s a sense of fear when it comes to using JS with Cognos – it would be naive to say it’s not a problem, but I think maybe developers are overcomplicating the JS and introducing developer tie-in with their code. What are you seeing?