Enter KALQ.  It’s an app that splits the keyboard in two, separating vowels and consonants and relegating less-used letters to the margins of your thumbs’ reach. Once users get a feel for it, researchers found they were 34% faster than their QWERTY counterparts.

Developers released KALQ on May 1, 2013, and it’s only available for Android at present, but it looks pretty exciting to smartphone users who are tired of having to apologize for texting something embarrassing to their mothers.

Read pre-release articles here and here.

Have you used the KALQ keyboard on your Android phone? What did you think?

MediaWiki has some great help pages, but when I had to transfer a huge spreadsheet from Excel into the wiki, I nearly tore my hair out. The wiki coding is a bit clunky and doing it by hand would have taken me days.

Thanks be to Google! I found a great online converter tool that is both simple and free: excel2wiki.

It’s dead easy – just copy your cells from Excel, paste into the text box and submit.

Voila! The result displays on the screen and all you have to do is cut and paste into your wiki page. Simple, right?

This has saved me hours of coding!

What nifty time-saving tools have you found recently?

The disclaimer is the best: “Warning: Scientific accuracy is not guaranteed. Please do not use this visualization for interstellar navigation.”

Got any nifty science sites you like?

big menus.

I mean, as far as details go, they’re a bit more complicated than that.  But the essence of a megamenu is that it’s a Great. Big. Layered. Menu.

Also, they’re a big trend now.

Big.

The more precise definition of megamenus is this: Megamenus are panels of links revealed by a user interaction. These panels are bigger, wider, and hold much more information than the menus you’re used to seeing.

Why Use Them?

If you have a content-heavy website, chances are that you have many different categories of information that users will need to be aware of and choose from.  One layer of information isn’t going to cut it because there are just too many options of equal importance that a user needs to get to easily.

Megamenus, if designed and programmed properly, can make it easier for your users to make those decisions, and give them a fast-forward path to their destination. Users don’t have the time to sift through your site, discover all of the options, and then carefully choose among them. Giving users an accurate and thorough set of links to evaluate means they don’t have to explore your whole site to find what they want; it also prevents them from having to pull up a model of their options from within their own short-term memory. I promise that they won’t forget that there is a section called “Scientific Research” because it’s directly in front of them.

Note the words easier and easily. Choosing among many options requires mental effort of users.  They’ll leave your site if you make things hard for them, so make it easy for them. Basic UX. Learn it; love it.

What It Means for You, the Designer

Again, ease of use is going to be what drives you, here. Megamenus provide a design space where multiple choices can be visually grouped. This grouping helps users make sense of the options available to them.

A big, unlabeled, unordered pile of links will just confuse and frustrate your users. They will leave.

Vertical menus don’t offer the layout flexibility. When vertical menus contain a lot of items, they can begin to feel overwhelming for many users. They will leave.

While designing and implementing megamenus, you can include icons, imagery, and even user controls like checkboxes and search fields. A warning, though: Triggering the menu from a user’s click in your megamenu is preferable to a hover. Activating menus by hover can cause a sense of instability that adds to user stress while attempting to interact with inputs / controls. Have you ever hovered over a menu item and tried to hover over to the sub-menu that pops out of it, only to have everything disappear? Horrible! They will leave.

Don’t make them want to leave.  Use this opportunity to find the balance between information and infodump.  Make it interesting rather than overwhelming.

An example of a mega menu that uses click, not hover, to reveal is NPR.org (see the ‘Programs’ and ‘Listen’ items.)

Articles for Further Reading

Mega Menus Work Well (Jakob Nielsen)
http://www.nngroup.com/articles/mega-menus-work-well/

Designing Dropdown Menus: Examples and Best Practices (Smashing Magazine)
http://www.smashingmagazine.com/2009/03/24/designing-drop-down-menus-examples-and-best-practices/

Counterpoint

6 Epic Forces Battling Your Mega Menus (Jared Spool)
http://www.uie.com/articles/mega_menus/

Start with needs*

Do less

Design with data

Do the hard work to make it simple

Iterate. Then iterate again.

Build for inclusion

Understand context

Build digital services, not websites

Be consistent, not uniform

Make things open: it makes things better

As a huge fan of open source in general, I feel designers (and PM’s, devs, etc.) do their part when they publish lessons learned and case studies. This list of principles applies to everyone working on the web now, and it is something our clients should read to understand the process. Honestly, I am pretty sure these principles (and handy examples) apply to more than just web nerds. For instance:

Government should only do what only government can do. If someone else is doing it — link to it. If we can provide resources (like APIs) that will help other people build things — do that. We should concentrate on the irreducible core.

We’ll make better services and save more money by focusing resources where they’ll do the most good.

What’s your favorite budgeting tool?

I stumbled on this great article about low-tech strategies to keep yourself organized and I loved that it put a paper notebook at the top of the list. That is something that everyone at Matrix has been asked to do as long as I’ve worked here:

• Always have a notebook and pen with you.
• Be ready to participate in an impromptu meeting or discuss an issue or take down a ‘to do’ item at any point in the work day at any place in the office.

Over the past few years I’ve stepped it up and now take my MacBook Air (thanks, Joanna) to meetings. It feels so good to take notes during a meeting, spend 10 minutes cleaning them up and then send them out to everyone. I no longer have to fumble around with papers and lose time trying to interpret my handwriting. Its also nice to pull up all the websites we’re referring to while we’re in the meetings.

There are so many great tools out there that help with real time productivity. There’s Google Docs, Evernote and even using our company Instant Messenger.

I now find myself creating my daily checklist in TextEdit or a Word doc. All of those stickies on my desk are miraculously gone! What I do is keep my checklist open all the time and refer to it throughout the day. I leave it up on my desktop at the end of the day so when I login in the morning, voila! I know what needs to be done.

This real time productivity has crossed over into my life. I always have my iPad next to me when I watch TV – I look up things mentioned on the news, I get reminded to “check out” when I see those Fab.com commercials that fly by when fast forwarding my DVR, and I’ll even pull up the long trailer of that movie they’re talking about.

Then there’s smartphones. It would be so 2009 to go on about smartphone productivity, so I will spare you.

To date myself, I grew up actually using fax machines, typewriters, pagers, car phones, 5″x5″ actual floppy disks and phone booths. By the way, what’s Superman using now??……guess that’s why a meteor hit Russia :-)

I love technology and the real time productivity it provides. Some people prefer kicking it old school. Whatever your pleasure, I’m sure 20 years from now the pen and pad will become hip again.

What’s your favorite productivity tool?

For years now (at least it seems that long) I’ve simply been passing my
variables from JavaScript to my cfc’s without any alterations.

I set my cfajaxproxy, define the cfc and give it a jsclassname, e.g.

    <cfajaxproxy cfc="ajax.ajaxFile" jsclassname="ajaxJSClassName">

On my js page I instantiate the class:

    var myAjaxJSClassName = new ajaxJSClassName();

And call the function in the cfc something like this:

$(document).ready(function(){
    $(".className").click(function(){
        curElem = $(this);
        curID = $(curElem).attr('id');
        results = myAjaxJSClassName.cfcFunctionName(curID);
    });
});

Fine. Not a problem. All works wonderfully.

If you opened firebug you can see the params of the ajax call and there
would be something like: argumentCollection{“variable1″:”12345″,”variable2″:”67890″}

I moved the exact code over to a CF9 site and I kept getting “WDDX packet
parse error at line 1, column 1. Content is not allowed in prolog..”

I tried so many things it was unreal. Stripped things down to the bare
bones. Updated JQuery. Took it out of JQuery. You name it, I probably tried
it.

So, back to the trusty firebug and I see that in the params the
argumentCollection was “51838EEB9C” no matter what I passed. I searched and
searched and couldn’t find anything related to this.

So, I’m now on the verge of removing the ajax functionality when I happen
across Raymond Camden’s site. It’s not exactly what I’m experiencing, but
it’s close enough!

So I change up my JavaScript to be:

$(document).ready(function(){
    $(".className").click(function(){
        curElem = $(this);
        curID = $(curElem).attr('id');
        var mydata = {data:[curID ]};
        $.post("/ajax/ajaxFile.cfc",
        {method:"cfcFunctionName",argumentCollection:$.toJSON(mydata),
        returnFormat:"plain"}, function(res) {
        })
    });
});

And wouldn’t you know – everything works fine now.

I’d like to know exactly why it wasn’t working in CF9. I presume that it has
something to do with converting the data to JSON, but try as I might to
convert it and put it back into my old code, I just can’t get it to work.

I’m sure that there are some smarter people out there than I that may well
be able to help me out. In the mean time any one else having such issues,
try not to bang your head against the wall for too long and embrace JQuery
even more. :)

UPDATE – 4/12/2013
So after another bout of hair pulling I came across some other articles.
Another Raymond Camden and also something from Andy Scott. The most helpful was the comments from the Raymond Camden article about caching of the scripts folder in the CFIDE folder.

I did a lot of things so I’m afraid I’m not completely sure which fixed it. But in the end I had a different copy of the cfide/scripts/ folder called scripts_901, and I changed Default ScriptSrc Directory in CF admin under settings. This seemed to resolve the issue. I then subsequently changed the name of the old scripts folder, and renamed the script_901 to be scripts, updated CF admin again so that everything looks like it was originally.

I hope this helps.

With modern text editors our markup is mostly written for us and in the case of certain content management systems (CMS) we hardly  need to write any HTML at all anymore.

Nevertheless as a web developer it is almost entirely impossible to forget about writing some markup.

I came across Haml and Sinatra about 2 years ago, through my interest in the Ruby language. Though I cannot say that I’ve gone on to create amazing web apps with these tools yet, I have found myself coming back to Haml again and again to rapidly flesh out some HTML when needed.

Maybe this post should have been called “writing HTML tables sucks” ‘cause that’s really why I find myself switching over to Haml on occasion.

My Sinatra Setup

Required items:

• Ruby: ruby-lang.org
• Rubygems: rubygems.org
• Haml: haml.info
• Sinatra: sinatrarb.com

First of all this is a super basic example and more than anything it is just a quick development tool. It’s a tool that gets used often and for that reason it should be completely painless and easy to get to.

Step one: This app needs a home, I use a local directory called ‘Sinatra’.

In there lives one ruby file and two directories each with just one file (the public directory is where you place files such as CSS, Images and Javascript – for this setup it is optional as I only use the app to generate some HTML):

/Sinatra

– app.rb

– /public (optional)

– – style.css (optional)

– /views

– – index.haml

The app is instructed what to display on what page in the app.rb file. The root page is set to display the index.haml view (a view is a template file in Ruby). Once the Sinatra and Haml gems are installed the app.rb is set up something like this:

require 'rubygems'
require 'sinatra'

get '/' do
	haml :index
end

Initialization of the app is done through the command line, first by navigating to the project and then running:

ruby app.rb

If all is good, the command line will say this:

Sinatra/1.4.2 has taken the stage on 4567 for development with backup from Mongrel

Now the app is viewable on http://localhost:4567/

All that’s left to do is write some Haml inside the views/index.haml file. No need to restart the app for changes in views/ or public/ just refresh the browser.

Protip: Because I use this so frequently and I always have a Terminal window (mac command line) open it made sense to create a command alias which will change my current location to the app’s directory. From there I am able to open the app in my text editor and initialize the app as well.

This has helped me a lot in the past and continues to be an useful little tool. Haml is just easier on the eyes and easier to write than HTML in my opinion.