https://en.wikipedia.org/wiki/NeWS
There was a simplicity and purity in its approach to front-end interactivity and rendering that completely eludes the HTML+CSS+JS stack we're now stuck with. As the Wikipedia article states...
"NeWS was architecturally similar to what is now called AJAX, except that NeWS coherently: used PostScript code instead of JavaScript for programming; used PostScript graphics instead of DHTML and CSS for rendering; used PostScript data instead of XML and JSON for data representation."
PostScript is basically a graphics-oriented Forth, so it's kind of a weird language to write directly... But it would have been great as a target for all sorts of interesting compilers and GUI tools.
Now that we have a web-aware platform (which NeWS was not), nothing stops us to create good UI tools on top - yet it is happening very slowly.
Also there is big performance impact, where piling up divs with CCS requires the right incantations, some browser version specific, for hardware acceleration to kick in.
And in any case, it is impossible to fully replicate the UX of the host platform.
How well does that work when your GUI must be shown in arbitrary devices, with arbitrary screen sizes and arbitrary resolutions? And how well does it reflow when the user changes the viewport size?
In any case, the original post to which I replied was comparing HTML5 to the NeWS platform, which provided a unified UI stack itself, so you wouldn't be able to match the native behavior following that approach either.
You are missing the fact that NeWS offered this kind of control.
"The NeWS Book" - https://archive.org/details/bitsavers_sunNeWSThe_11666863
https://www.usenix.org/legacy/event/usenix2000/invitedtalks/...
The reality is every platform offers it's own encouraged design patterns and to create the best UX you need to maintain builds for each platform.
In the next 5 years I don't see JS being replaced as that cross-platform runtime, but maybe a transpiled strongly typed language could become defacto.
Standardization exists. In two ways. Either your brand has a standardization or your platform does. Both work. It's like saying "we only need one coding language" when the reality is quite different.
The disconnect is when brand isn't as complete as platform. Granted, platform has really only fallen into place in the last few years for iOS and Android. But does brand really need standardization initially? No. Because new paradigms need to stand out, either for UX or for impression. Otherwise AOL would be Snapchat, and it ain't.
I respect that coders don't grok product design fully or in parts. But please understand, a great deal of the fun, the joy of tech, is in UI/UX evolution.
The only shake-up UI-wise in the last 10 years was the introduction of smart phones, which meant the need to design for smaller screens, as well as work with gesture commands. Instead of adding to what we had, we spawned Bootstrap on the Web, Android has it's own custom widgets, as does IOS and so does Windows Mobile. This is the divided state of technology we live in. A smaller screen somehow communicated to people we need four new GUI frameworks.
This result stifles design, because if I design for IOS, I have to re-make everything again for android (including any custom controls, themes and so on). This has a cost, I can't support android UI controls if there doesn't exist the same on IOS, or other platforms. So people might choose to layer Xamarin on top, essentially throwing another framework into the mix. Why do we need so much abstraction?
Recently I've switched my desktop project from WPF to Eto.Forms, so it can also target Mac and Linux. But the result is I now have no mouse drag functionality, because that isn't implemented yet. These are real limitations I face everyday. What exactly is the problem I wonder? We are literally talking about squares with text/images on here. It is mind boggling.
Swing has been deprecated in favor of javaFx for a while now.
As for the lack of Swing/JavaFx on Android, I don't know if there is an official reason.
It could be that Google only wanted to take the language and replicate everything else in order to avoid lawsuits.
Another option (and they are not exclusive) is that you take a lot of cruft with you when you integrate something like Swing.
Also, widgets like RecyclerView are really complex and do some deep optimizations like pre-binding views when the ui thread is idle. Having ownership of this part of the stack in order to make it evolve might have been considered worth the development cost.
Here's a little sneak peak: https://twitter.com/laktek/status/845815533450682370
Currently UX designers are often like chefs who work by drawing pictures of food and writing down conceptual recipes. When they've created a beautiful menu this way, they're surprised to find out that their recipes can't actually be made using the cooking equipment available, and some of the ingredients don't even exist. You're not going to run a Michelin-rated restaurant like that.
The industry desperately needs better UI development tools. To continue my (already strained) food analogy... Right now we are still in a "hunter-gatherer" stage where everyone does their own thing, teams are foraging and hunting, and occasionally they stumble on something great. Consistent UX will require an "agricultural revolution", a systematic production innovation that makes the essential pieces more understandable and repeatable in isolation.
Designers should definitely work with devs, if they are surprised their designs can't be implemented in the end, then that organization is REALLY dysfunctional.
We definitely need better UI development tools, but this is orthogonal to UX design, much of which doesn't even involve the aesthetics of the UI anyways.
Designers should definitely code. Too much of design is siloed in fanciful thinking, and fancy people competing with fancy people over fancy things perpetuate delusion.
I am a designer who codes, in fact my background is UX and my job is as a developer. It's easy to think about implementation during design, for example, designing a web-app and knowing it will be implemented in Angular leads to thinking about how Angular will implement it, leading generally to modals everywhere, just everywhere. If I knew nothing about the technical implementation I wonder if it would be a smoother design process, possibly better results. But then I see so much poor design everywhere that I can never be sure if something was designed by a coder who knows little about design or a designer who knows nothing about implementation.
Imagine if Apple hardware designers depended on their manufacturers to tell them what's achievable with aluminum and glass. Instead Apple has a small manufacturing facility in their design studio so the designers can iterate rapidly and actually understand what is possible.
Also, it's far more common that organisational culture, law, or the marketing department is a bigger constraint than the code stack. As a designer, I should consider my "medium" to be far broader than knowing some CSS, or I'm not doing my job.
Being a good designer is inherently being a generalist, and in being a generalist, the designer should understand some basic things about programming in order to have common ground. But that is certainly not the same as saying "designers should code". If designers should be programmers, then they should also be accountants, customer service, marketing, operations, lawyers, c-suite, and every other profession they interact with to solve a problem.
Designers have their own tool chain to prototype UIs and user interactions, but these are not UI devtools.
You mention that designers have their own toolchains for prototyping, but these has nothing to do with UI dev tools. I've often wondered why this would have to be so.
Look at other advanced design fields like architecture and industrial design. It would be unthinkable today that professional architects would just draw a facade and not use CAD to actually model the structure. Similarly, it would be very unusual for an industrial designer to model a product using a toolchain that is entirely separate from manufacturing. The assumption today is that CAD and CAM work together, not separately.
Why can't we have the same in software? For my part, I've been trying to work on a solution in the form of apps like React Studio [1]. It's not there yet, but I'm convinced that proper software modeling tools will happen eventually.
> Why can't we have the same in software?
Because devs and designers have different needs.
I make products that ship, people like, and can be further developed in both design and code by specialists. That's good enough.
To deliver a really great user experience, it's really important to not just look at the interfaces between the customer and your products, but instead try to figure out the "flows" and processes that leads to that the customer uses your platform or app.
In some domains, you will need an awful lot of domain knowledge, paired with UI design expertise, modeling and development skills to do just that.
Typically, it's very hard to find all this in one single person, so excelling in teamwork is always a good trait.
Does it enhance accessibility? Elucidate the IA? Or is it just more whiz-bang?
The current state of tools doesn't allow designers to think in terms of actual UI components and navigation structures. Instead, they are forced to draw pictures and make animated slideshows. This leads designers down a path of tweaking aesthetics because that's what their tools are designed for. (In this regard, newer apps like Sketch and Principle are not fundamentally different from Illustrator or After Effects.)
We should have tools that allow designers to think in terms of higher-level UX components with the confidence that the designs can always translate into code.
I worked on two products that came from this school of thinking, Neonto's Native Studio [1] and React Studio [2] (they're both variations of the same codebase really). I know someone will bridge this gap eventually...
[1] https://neonto.com/nativestudio [2] https://reactstudio.com
What?
*EDIT: TIL, Qt is GPL, but offers a lesser licence for a price. For some reason, I didn't know that.
I was just giving an exemple where LGPL isn't possible.
ConstraintLayout is pretty much AutoLayout without the bad parts, Databinding makes declarative style UI easy to write.
It is not perfect by any means, but it is definitely improving quite steadily.
They focused on making it run fast by making it compile to bytecode and make the same minimal calls you would make in java .
It is true that it is not a new idea at all though
Java has JavaFX now
With some minimal effort, it's possible to do a nice looking GUI with fonts that not look like vomit, etc.
If Sun and Oracle had spent more than 5 minutes on packaging applications - why not in jxe-files for executable jars, as a simple start to avoid torturing your users - and using nice fonts - and why not a discrete and non-whiny non-bundlig autoupdating jre - they could actually have won on the desktop, when it still was relevant.
Sun is the one to blame, as traditional UNIX company their Swing team just didn't had any clue about the desktop world, outside enterprise walls.
Oracle is actually doing much more than Sun ever did, they introduced a way to package applications with Java 8, originally part of the JavaFX project, and are adding support for AOT compilation (it was tabu at Sun) and application specific runtimes.
If they had defined and promoted using .jxe as the file name extension for executable jars, there had been so much less confusion for the end users.
(Just like they have done with ear, war, rar, etc)
Also, the security considerations for java web start applications where rather strange, with ugly icons warning that you were running a java application etc, and much higher requirements for certificates and signed executable compared to just about everything else that you run on a computer.
If they had re-imaged the framework to use a "installation" and providing automatic updates, just like normal applications, they could have lowered the bar a little.
Personally I think it was a good move to go back into native UIs, right about the time people were starting to adopt Angular.
UX % UI = ?
Is it a feeling or a thing perhaps?
Then you get the layers on top, Xamarin or Eto.Forms or X, that convert down to the native widgets or just create their own entirely. These usually come with a healthy dose of missing functionality, such as mouse drag detection.
And then there are the languages with no UI libraries at all. As if this is even acceptable in 2017.
All in all, whoever decided GUI frameworks were a good idea got it very very wrong indeed. This stuff should have been standardized long ago, stored in some universal data format, and then every programming language could add support for it. They would want to add support for it. Closest to this is HTML of course... but, well, I think everyone would hope for something more elegant.