HN Explorer

GUI's still the pinnacle of productivity, let's help them out

5 points by tabtab ↗ HN
Ignore specific technologies, standards, and programming languages for a thought experiment. What's the most productive UI design for regular office productivity? The answer is still GUI's, a technique that's several decades old. All the focus on finger-based mobile and social networks hasn't changed this fact.

While it may be possible to build a highly-productive mobile-style UI, it's difficult to get right and/or requires more user training. The mobile UI world is a sub-set of GUI idioms, for the most part. This means you are more constrained; working with a smaller pallet.

Desktop-style GUI's can fit more on a given screen because the pointer is smaller compared to finger aiming, can have roll-over text for cryptic icons, right-click options, nested pop-ups for drilling down into progressively further detail, and others.

Emulating full GUI's in web browsers has proven tricky. The emulation libraries are huge and often break when new browser versions or brands come along.

If the industry faced the fact GUI's are not going away any time soon, perhaps it would form a good GUI-over-HTTP standard. It could roughly resemble Microsoft's GUI XAML, but be cross-platform, "stateful", and interactive. The Tk or Qt engines maybe can serve as the base for a "GUI browser" or browser plug-in.

4 comments

[ 6.2 ms ] story [ 21.4 ms ] thread
ktpsns
XUL (Mozillas XML-based widgets) or JWS (Java WebStart) seem dead, but I don't know why. They could provide exactly what you ask for -- zero install rich interfaces with better performance then HTML-based ones.
tabtab
I found XUL kind of cryptic and round-about. Maybe its philosophy somehow paid off in the longer run, but it's not newbie-friendly, discouraging fiddlers and experimentation.

And Java damaged its client-side reputation via the Applet fiasco. Namely over-extending itself by trying to be an entire virtual OS, and not paying enough attention to security.

Lessons from these: K.I.S.S., don't drift from mission, and security matters.

przemo_li
Actually, what killed both is market size.

Internet boom === small simple apps where emphasis is either on looking good or being very responsive.

That meant that vast majority of developers where not in a market for rich GUI stuff, but for better CSS and smaller size.

OTOH desktop never rewarded simple apps. Distribution and marketability asked for more features exposed via GUI, thus most developers where OK with bigger in scope GUI stuff.

As for "next browser breaks your stuff" excuse, I think it wasn't true for a very long time now. Include polyfills, css defaults reset, do transpiling into less features and you are good to go.

OTOH, web underwent multiple groundbreaking shifts in computational models. This is why complex but somewhat encapsulized/localized Angular/Ember won over spaghetti inducing predecessors and why truly encapsulated/localized Reacts eats old Anguler for breakfast.

One last point would be about crazy stuff in programming languages / programming paradigms that was already available in 60's and 70's at least as a statements of need. Those made for very stable platform on which GUI ecosystems could be build. Relative instability of JS with generational changes can explain why it gets a new ecosystem every few years.

tabtab
Big GUI apps don't need a big download packet, assuming a good "GUI browser" that can shift most domain logic to the server. Just make each window/form/panel an independent packet. An application can have say 5,000 forms, but if you only activate 30, then it only downloads 30 (plus a few reference files for constants and defaults. A pre-loading a larger set perhaps can be on option.)

Re: "As for "next browser breaks your stuff" excuse, I think it wasn't true for a very long time now."

I'm not convinced yet. It may be improved, but not solved (mostly because IE can finally be considered dead.) The current candidates have long learning curves, are version fragile, or both. Corporate products tend to target specific browser(s) to reduce the version risk, but that's not really solving the problem, it's reliance on a mono-culture just like MS-Windows.

Regardless, IT still needs a stateful GUI markup standard, at least to help desktops be cross-platform. It would improve desktop standardization even if the Internet ends up ignoring it. The X Window System is a useful idea, but is designed for LAN's instead of WAN's and internet, partly because it doesn't buffer UI i/o, creating too much interaction latency.