|
Being a web page makes it harder to make a grid control usable. It makes it harder to make ANY control usable.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
#realJSOP wrote: Being a web page makes it harder to make a grid control usable. It makes it harder to make ANY control usable.
That may change with the migration away from JavaScript to WebAssembly.
|
|
|
|
|
… is in the fans and the (non-SSE) hard drives! 
Socialism is the Axe Body Spray of political ideologies: It never does what it claims to do, but people too young to know better keep buying it anyway. (Glenn Reynolds)
|
|
|
|
|
What we need is holographic displays, any size, any resolution and probably 3d. I thought more would be done with Kinect but that seems to have fizzled.
Never underestimate the power of human stupidity -
RAH
I'm old. I know stuff - JSOP
|
|
|
|
|
A colleague of mine regularly states that "What we need is infinitely fast machines, and lots of them!"
|
|
|
|
|
A grid is very rarely the right tool.
|
|
|
|
|
A web page is very rarely the best UI
|
|
|
|
|
"A web page is very rarely the best UI"
Web page can be any UI you need it to be. The problem is web app designer, not the web technology itself.
|
|
|
|
|
I strongly disagree. The underlying technology is the reason creating a good controls for a web app is so difficult. Using a browser for applications was and still is a horrible idea.
|
|
|
|
|
Yes, it's hard to make good UI widgets/controls. That's why you don't make the controls yourself but use some UI library/framework to build your web apps. You can use DevExtreme, Kendo UI, webix, Ionic, Sencha ExtJS and many other advanced UI toolkits.
Also, when you are creating Winforms/WPF or any other .Net UI framework apps, you don't usually build your own basic UI widgets, but use built-in stuff plus some 3rd party framework (DevExpress?).
|
|
|
|
|
I have an online game I developed over many years. I create a web-based UI to interact with it and it was a nightmare! I had fun with SVG to create the multiple zoomable, clickable, scrollable, hover-overable maps needed but apart from that (which was only a small nightmare) the rest of it was horrendous!
I wrote a WinForm program that used a web-service to get data to and from the game server and it was a joy to write. Everything just worked as it was supposed to, clicks and hovers, etc just responded instantly the way I wanted. I was able to get it done so quickly compared with fighting with the web programming that I could add dozens of extra, useful features. All the friends I had that were play testing for me adopted it in easy preference to the web UI (except for the guy who had a iCrap PC instead of a proper one and so used the Web UI).
The Winform program updated itself automatically from the server each time it started up (if necessary) so there were no issues with it being out of date (one of the arguments in favour of a web interface although there are often caching problems that can break this "advantage") so I just would push out updates whenever I needed to.
WinForms rule!
- I would love to change the world, but they won’t give me the source code.
|
|
|
|
|
|
Part of why I don't do that Web crap.
But even in WinForms, grids are a bad idea.
|
|
|
|
|
I am not always so sure that it's the controls that are the issue, but more how much thought that has been put into what information the users need and how they can access it.
Why not stick an excel export on the page if users needs to view a huge amount of data and analyse it in their own idiosyncratic way. Because if you start designing all those fancy analytics systems the users want you will end up with a mess of code and UI.
I think some modern UI design has tried to promise users things that just don't make sense and that end up being really messy - take the redesign of skype it's one horrible nasty mess of ideas all slapped together in their gooey rawness.
I am still using software(Microsoft Money 2005) that is now around 15 years old to do my finances - it does not have all the modern UI prettiness but it works and gives me the information I need.
[Edit = typos fixed and tidied up]
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
modified 29-Mar-19 9:57am.
|
|
|
|
|
GuyThiebaut wrote: I am still using software(Microsoft Money 2005) that is now around 15 years old to do my finances - it does not have all the modern UI prettiness but it works and gives me the information I need.
Count me in on that. In fact I'd still be using the version before that if it actually installed and behaved correctly on modern operating systems. (As I recall, it had a thread that is constantly burning up CPU time without letting go)
|
|
|
|
|
Interestingly enough it seems like Microsoft fixed the registry issue because I recently upgraded to Windows 10(I was a very late adopter because of the Microsoft money issue) and I did not have to perform the registry hack, Microsoft Money 2005 just works from the installation ISO on Windows 10 Professional on my computers.
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
|
|
|
|
|
I never had a problem with Money 2005. I was talking about the version prior to that.
(I just looked it up in my archive folder...it goes back to 95 (!)...I suppose not being able to run nearly 25 year old software isn't such a big loss after all...I could perhaps set up a VM, but I'm okay with 2005)
|
|
|
|
|
While 3D may offer better possibilities to handle more data, it will get cluttered sooner or later anyway. The solution is less data. What about a graph that summarizes the important metric or relationship between said metrics instead of a grid?
|
|
|
|
|
Are you the same Marc Clifton I just quoted on [^]my web page? Then obviously, you are very dissatisfied with web-based UI UX. I can inform you that the revolution you seek happened ages ago. It merely got hijacked by the interpreter lovers. But now that security is finally a big thing, code-injectable interpreters are out. Left standing are native code developers.
I suggest you take a look at this native C++ code UI suite (but also C# if you insist on throwing security away): consider BCGSoft's C++ MFC control libraries. While the developer world has been chasing the latest language fad for the past 20 years, these guys (and my project too), have stayed with C++ MFC and non-web UIs. Consequently, their controls are fabulous. Just take a look at these [^]Grid Control Features. Collapsable grid rows with variable heights with spark-line graphs at row end with infinite number of virtual rows? Yup.
|
|
|
|
|
We could make long strides by simply using what we've got in much more sensible ways than we do!
I regularly get into discussions with CLI affectionadas (read: Linux people) who insist that workin in a CLI is so much faster, sometimes they say "streamlined", than a GUI. To illustrate it, they pick up some terribly designed GUI where you have to jump from tabcard to the other, type in by hand a word for 1-in-n selections, it remembers nothing of preferences, etc. etc. I have seen input fields tagged by the single-character CLI option letter, rather than a text indicating what the value represents!
Why should a software developer be bothered by learning anything in the application domain, about work patterns, terminologies and how things looked and are operated outside the computer? An example: When I needed a sound editor, I ended up on Steinberg Wavelab, and a number of my friends and colleagues screamed out: Why do you waste your money on that? Couldn't you use Audacity? (or Cool Edit or this or that) I force them down on a chair in front of my PC, and show them: To do so&so, here is how I do it in Wavelab ... And here is what I have to do in the system you argue for. To do this&that, here is WaveLab ... and here is yours. Wavelab was developed by people who know how the tools are used, which operations must be easily accessible, how the normal workflow is. That is why I chose Wavelab over the cheaper/free alternatives.
It repeats with all kinds of software. Photoshop didn't become the leader beacause of functional features (Gimp wasn't that far behind!), but because things "feel right" when you work in it.
Even document editing: MS Word is developed based on tons of logs of how the users work - where do they make mistakes? Where do they spend more time to do an operation strictly necessary? Which features are used most frequently and must be directly accessible? and so on. LiberOffice developers do nothing of that sort, and working in it feels much more clumsy. (And it is NOT "just because you are used to MSO" - I have several times demonstrated, like I did with Wavelab, how much more streamlined MSO is.)
The now historical "Common User Access" standard was what made Windows win the marketplace. Users felt at home, safe, they knew what to do even in a program they had never seen before. Standard controls were placed in standard locations. Application independent terms were consistent. There was one way of selecting one-of-many, displaying a directory tree etc. This won over technical quality by a huge margin.
When GUIs came to the *nix world, it was proclaimed "mechanisms, not policies". In other words: Every developer should do it his own way, not learning from others. The user should have no benefit from conventions and standards for how to do things, and which functionality to support (from cut&paste to adjustable text size). Why should we cheapen it by making it obvious what to do?
Linuxers seem to insist that the only possible way, even theoretically, to run automated jobs (take regular backup as an example) is through a 7-bit ASCII text script activated by cron. Selecting directories, setting up filters, exection plans etc. in a GUI - they have no clue that such things exist at all. That it is even theoretically possible.
So when they set out to make a GUI, they model it by the CLI, so that old CLIers can map their well known option letters directly onto a form. Sorry, that doesn't make a good GUI.
Bottom line: Let us not wait for anything new and shiny that will solve the problems automagically. Let us rather spend resources on making GUIs with the tools we've got to be as good as they can be.
That requires that we learn a lot about how the users think and work. You can't do it in the basement of your parents' house. You can't work in a software house delivering (the same?) tools to everything from fish farming to brokers to artists. You must go out and learn about the users and their needs. That is not the most prominent characteristic of developers of free and open source software!
|
|
|
|
|
We need a totally different web technology, HTML 500.0 or something else.
TOMZ_KV
|
|
|
|
|
I always look a step further ...
For me, the big problem is not in views, data, and UI, but basically in interfaces in the communication between man and machine. Every day, when we want to bring our thoughts and ideas to a conclusion in our work, we are always slowed down. Whether it's keyboard, mouse, or whatever, the ideas in our minds can never be written, developed, and tried so quickly.
As non-English speaking, it took me 2 minutes to write that, get the syntax check over, and then post it! Everything so long only because of these not practical interfaces. 
Something about which we often break our head:
"In the name of the Compiler, the Stack, and the Bug-Free Code. Amen."
(source unknown)
|
|
|
|
|
I knew what you were saying. With current "advanced" technology, we in fact have to do a lot of primitive/simple things. See what AI will bring us.
TOMZ_KV
|
|
|
|
|
Tomz_KV wrote: We need a totally different web technology, HTML 500.0 or something else.
What about WebAssembly?
|
|
|
|
|
It is still in its infancy. It may take several years before we see an answer.
TOMZ_KV
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
