2015-12-28

SSL is dead. Long live TLS.

Hmm, do you think there are any other protocols that could be resurrected with a different name? How about good old HTTP? It hasn’t been about “Hypertext” transport for a long time. I mean sure, HTML is still around, but half the time it’s being written on the fly by your Javascript app anyway, not to mention there are CSS, SVG, images, audio, video, and a host of other things being transported via HTTP. And it’s not just passively transferring files, it’s communicating complicated application responses.

Maybe we should just call it Transport Protocol, “TP” for short. Yeah, I like it!

Happy New Year!

“Provably fair” elections

When I read this article on BitZino (go ahead and take a look, I’ll wait…) I couldn’t help thinking about elections.

It does seem like it would be pretty easy for an online casino to rig the games. This is a really awesome use of technology to prove that something is fair (even if I think gambling is stupid; I try to stay out of games that are stacked against me).

So if we can do this for card games, why not elections?

Continue reading

How I learned to let go and love Gnome 3 (sorta)

When Gnome 3 first came out, I had some problems with it. I think everyone did. It was a radical departure, to be sure.

My biggest problems, as I recall, were:

  1. Someone made the laughable decision to consider multiple monitors as one workspace accompanied by a fixed screen (or multiple fixed screens with 3+ monitors). Meaning, if I switched to a different workspace, only the view on one monitor changed. For someone who likes to maximize real estate during development, this was utterly unworkable. There was some hue and cry about this, and eventually (in the last few months) this seems to have become a proper configuration option – it still defaults to this behavior but you can change workspaces to include all monitors with the gnome-tweak-tool. At the time, the only workaround was an unsupported option, which probably contributed to 2.
  2. On the particular machine where I was trying Gnome 3 on Fedora 16, it was completely unstable. The desktop would randomly freeze every day or so without any pattern to the problem that I could discern.

I tried Fedora 17 when it came out. Some things had settled down, but there were still some stumbling blocks. I actually switched to XFCE for a while as that seem to fit my habits better. But I missed some of the razzle-dazzle, particularly the gnome-shell overlay way of finding and starting apps – old-school menus seemed so clunky after Gnome 3.

Two hurdles kept me from returning to Gnome 3 for a while.

Continue reading

“Your call is important to us”

It’s clear this phrase needs an addition: “… but not important enough!”

You know, I understand that call volume is variable. I think if customers and their calls were actually important, staffing in the call center would be such that you almost never hit this message. The fact that you have to reassure your customers that you actually care is evidence that you expect your customers to believe otherwise. I wonder if anyone has done studies to determine if this kind of message is at all effective?

How could this hollow message be avoided?

  • Obviously, the call center could staff for peak traffic. This wouldn’t have to be wasteful. You could arrange shift changes to overlap during peak times. You could have employees doing non-call work (e.g. training, online tickets, knowledge base / docs…) during non-peak times.
  • Your automated phone system could be asking questions while waiting in the queue – the same questions that the representative would be asking anyway – and just connect you to the representative when one becomes available, passing on all data yet received. This way the customer would at least feel like they’re accomplishing something rather than pointlessly waiting. I know, having a representative actually receive the information you enter instead of having to re-request it seems like a novel idea, but I have actually seen it done. It is possible.

By the way, Bank of America, screw you and your crappy service. Cold-transferring customers to someone with no idea of who I am or what just happened with the previous representative is no way to run a decent operation. I am so sorry I ever did business with you.

Actual technical question: when calling 1-800 numbers, I like to save minutes and use Skype. Whenever I call e.g. conference numbers at work, my connection always seem fine. Whenever I call customer service numbers, I can hear them fine but they can’t hear me well at all. Is there some technical reason for that? It seems universal, not just like one customer service organization is giving me the shaft.

Please Steal This Idea: enhanced phone trees for smartphones

Calling for support really sucks. It sucks more some places than others, but it sucks everywhere. And guess what… it sucks for both sides of the conversation!

I think it’s preposterous, now that I have a smartphone with a touchscreen, to say nothing of Skype and other VoIP solutions, to have to listen to a serial voice tree of options. “Wait, was number 3 what I wanted? Maybe it was 5, what was that again? Oh crap… nothing on this menu sounds like what I want…” And thus do we fail to connect to the right place, frustrating both the caller and the eventual recipient.

With a video display attached to the phone, the least we could do is present the options in parallel on that screen. Shouldn’t take too much bandwidth to send this as a blip at the beginning of every menu; each phone client would require some kind of application or hook that intercepts the blip, displays the menu (which the user can scan back and forth as needed), and turns the user selection back into a phone signal. And if the user isn’t calling with an enhanced client… fine, they’re stuck with the traditional voice reading.

Better yet, the entire tree of potential choices could be communicated at the beginning of the call, the user could walk it at their leisure to find the path that seems optimal for them (perhaps with projected answer times at each end node), and then skip right to the end node where they’ll be connected. And that tree and preferred choice could be cached for the next call, where it would be compared to the tree at that time (avoiding the “our menu has changed” sentence that always makes me wonder “since when?”) and usually re-used.

That would make for a lot “smarter” phone.

If someone isn’t already working to bolt this on to the existing phone system, I hope it’s because they’re targeting something like this in the next phone technologies, which won’t be analog. Maybe there, we’ll have a nice multimedia intro when calling, not just voice or text. You could even have little games to play, or information to start filling out, forums to check, etc. while waiting. To turn this inside out, perhaps in the future, contacting support will begin with the support website and only get to the audio/video call once it has been determined who you are and what you want, and the person taking your case is available to talk to – in the meantime you’re not sitting there listening to hold music, you’re potentially making progress toward your solution on your own, or at least amusing yourself.

Slinky menus for increased usability – clever or tried+failed?

How many times have you started up a new application and been overwhelmed by the sheer number of little buttons and menu options you can pick from? I’m thinking OpenOffice or the GIMP here. If you’re a n00b it’s pretty daunting. Heck, even for an expert it’s cluttered and annoying.

I’ve seen attempts to present different levels of interface to different experience levels. Thing is, the nomenclature can’t help but be condescending. With levels like “Basic, Intermediate, Advanced” who isn’t going to feel like a wuss for staying with “Basic”? Anyway, the whole interface changes, which may not be helpful for finding the specific thing you want to do.

So here’s an idea that I’ve not seen implemented (someone please let me know if this has been tried and how it worked out). Rank each option by how common its use is (the developers could guess, use focus groups, or collect usage data from existing versions). Start with menus/toolbars displaying just the most common options. Then add the ability for each menu and toolbar to be expanded or contracted by grabbing the end and pulling it. This could work for sub-menus too. The bigger the menu or toolbar, the more esoteric the options that appear on it; and they don’t have to appear at the end, they could appear sensibly grouped with other related options.

Several benefits fall out:

  • If there’s a menu or sub-menu you use a lot, you can expand just that to your taste and leave everything else comfortably uncluttered.
  • The designer could put the same option on several menus (often it’s not obvious that something belongs on only one) without worrying too much about contributing to clutter.
  • Don’t need to add yet another button or menu item or preference to control how much interface to show – it’s totally intuitive right where it’s needed.

The only reason I can think of for not doing this is that someone’s probably already patented it and put it on the shelf. What do you think?