evolving the interface (based on euromnis observation)
Doug Easterbrook
doug at artsman.com
Thu Dec 19 14:20:28 EST 2013
hi Faez:
absolutely - and its really quite simple notion. There are a couple of points about the answer though worth bearing in mind.
First: technically & forward looking.
We've been building Theatre Manager for nigh on 30 years with Omnis - way back to the omnis 3+ days. We've been in studio for a fair long while and we've greatly enhanced the interface, adding icons, buttons, tooltips, tabs, lists, background searching (big vote for threads) and lots more. I like it. my customers like it. It's great.
BUT (and that really was really for emphasis)... I MISSED MAKING A KEY OBSERVATION. more to the point, I missed part of the feedback loop for some recommendations I'd been making to clients. I got skewered by the boiling frog syndrome. (http://en.wikipedia.org/wiki/Boiling_frog).
Go back a few years: Clients asked what kind of monitors to get. I said. "don't do those old CRT's -- go for LCD's. They've come down in price and you'll like them better on your eyes -- oh and don't forget to buy at least 1024x768". Those words are hardly groundbreaking looking backwards, but really was a bit of a risqué approach back then. Of course, the clients were happy.
Roll forward a few of those years and the prices drop dramatically. Clients still ask what to buy. I say "the price of the widescreen monitors is pretty close to the standard LCD's. Go get wide screen .. you'll get more data on in front of you for the same price. oh, and they are fantastic for speadsheets".
Now, I'm the frog and this is where I start to get boiled alive. Pretty soon nearly all my customers get wide screen 1080p 16:9 -- you name it ( I think they all watch movies at work). I rarely run into an older 4:3 1024x768 ratio.
Trouble is, we've built our interface on monitors with a greater height to width ratio than the plethora of monitors in use by customers. The interface takes up menu bar, toolbar, window title, tools on the window, message area, buttons below lists. A bunch of the application is built with data at the top and lists at the bottom I've basically taken 30%-50% or so of the height of some windows for application buttons, pathing, menuing, controls, etc.
which, when you think about it, is really kind of stupid and I'd never do it again but it was so ingrained. This frog is truly boiled.
So enter the second point I would like to make:
At Euromnis this year, Dave McKeone saw some work Marten Verhoeven was doing. And as soon as he saw it, he said "Doug, you have to look at this!!". And as soon as I did -- i realized how boiled I was. I neglected to see that a fundamental paradigm shift had occurred with hardware. Hit by a 10 ton load of bricks. People who buy monitors buy widescreen and nothing else.
Well, if you get widescreen, the controls should be at the SIDE of the window. Action buttons down the SIDE. If you do that, your lists get a whole lot more VERTICAL real estate on them and your application becomes a whole lot more useful to customers because they can see more.
Doesn't matter that I'd been telling people to buy them -- I completely missed the cultural implication -- and therefore the design implication on how our application should look. Boiled.... through and through. and Marten has a couple more ideas -- and I like them.
The second point I'm trying to make is -- it takes getting together with others, discussing techniques, observing, listening. Each and every year we go to Euromnis and, while we present topics on what we do, we also take time to listen. I can tell you the huge excitement when I first met Michael Monschau sitting outside one of the conference rooms playing with an early version of oWrite. (out of that came hugely marketable functions in our app with owrite, ocal, ospell, ogantt, eblasting, logging, html like interfaces and links, some of which we describe in Scotte's dating game sessions). And then there is Kelly Burgess sessions from the past. Now we use dragster and imagebox through-out our app. TCP talk was a huge life saver when we were in Classic worlds. We use it less now, but we still use it for things like auto discovery of bonjour services (like the postgres database) around the network. Imagine starting up a client and it just finds the database on the subnet? How cool is that. Don't get me talking about RFID potential, the potential of using python in the database.
Sometimes just talking to people reinforces what you don't want to do. We were trying anything we could to get more performance out of omnis. There is 'async methods' in the language. We'd been playing with them and were getting hung up -- things went slower. Well, when you end up talking to others who have tried it and then you get into a discussion with the Mitford team -- you understand the original intent.... which was completely orthogonal to what we were trying to do despite the name of the commands.
And our lists of data were loading somewhat slow (10 seconds for a hundred records). made no sense. So, enter a couple of late nights at the bar pouring over code, talking to others and 'voila' --- we finally fully understand the root methodology of how omnis manages changing data in lists. If you know how the current record buffer works and how lists adjust and you change data in them --- then a few short coding style changes, and now our lists load in microseconds. No magic changes to omnis - just small changes to our code to take huge advantage of how omnis works.
I know, I sound like I'm talking up Euromnis. You are right -- I am. More to the point, I love this community because people are inquisitive and ask questions. and sometimes you just need to get together because the hundreds of steps forward that are taken far far far outweigh the cost (as I see it). And each year, we always map our development plan based on what we learn from talking to others.
Faez: It was long shaggy dog story. The frog got boiled and now you know the fundamental reason why I need to change my already fantastic interface .... because it can be made 10 times better with little effort. Thanks Marten!. I owe you one.
(thanks for asking... that was quite cathartic!!!)
Doug Easterbrook
Arts Management Systems Ltd.
mailto:doug at artsman.com
http://www.artsman.com
Phone (403) 536-1205 Fax (403) 536-1210
On Dec 19, 2013, at 10:00 AM, omnisdev-en-request at lists.omnis-dev.com wrote:
> Hi Doug,
> Could you share what was so unique and cool about this interface that you saw, that has caused you re-evaluate your own interface.
> cheers
> Faez
More information about the omnisdev-en
mailing list