101–110 of 144 posts
They have a FOSS version behind that confusing website, the livecode.org site has access to the GPL version, you can download without acquiring a membership. It is just a bit hidden.
something that works for kids but also scales all the way into enterprise.
Earlier quoted context omitted.
Gosh, I didn't realize my new MBP had such a bad screen. Low-contrast UIs can work well in a typical office environment on bright screens. Take your ideally calibrated monitor, and use it as a second screen while watching a movie in your darkened home theater. Now take it and use it outside on a sunny day. I prefer to adjust the brightness. YMMV. Your description of sRGB is incorrect. sRGB was specified for CRT scree…
MBP? That's surprising to hear then, they've got great (not $1600 Dell HDR monitor perfect, but great) monitors. One of the core issues is constantly fiddling with the brightness, especially with multiple monitors. That's where ideally you'd want to have the brightness of the panel fixed, and change it with a lookup map, e.g. what f.lux does for color mapping at night. That's where you'd get ideal results, would be a…
And then you'd probably need to throw in an adjustment for the individual user's light sensitivity needs and preferences, and possibly the user's current eye dilation (did I just go from bright light into a dark room? Or did I just wake up in the dark room?)
You can design for an ideal environment, but realize that users will not always (ever?) be in that ideal.
there needs to be ways to jump into code without being bogged down with installing compilers and tools and configuring minifiers and choosing frameworks. just code straight away. something that works for kids but also scales all the way into enterprise.
Earlier quoted context omitted.
What I find amazing is that early B&W GUIs were more usable than modern material design. Most takes on Material that I’ve seen take poor use of screen real-estate, poor conveyance, and distracting/hard-to-read color choices to an art form.
I've been very interested lately in the idea of monochromatic interfaces. Aside from being easier on the eyes (especially an amber or red interface), they force UI designers to make careful choices, and potentially result in a cleaner, more useable interface. It's not a project for me yet, just a series of notes and concepts, but I'd like to turn it into a proof of concept at the very least.
Earlier quoted context omitted.
It's pretty much in the same ballpark.
Having used both, Scratch is nothing like Hypercard at all. Hypercard was very simple to start with, but you could produce properly powerful programmes with it if you wanted. A closer analogy would be to the fully featured Logos you could get in the late 80s which looked like simple drawing languages on the surface, but were actually pretty full-featured LISP implementations.
Earlier quoted context omitted.
MBP? That's surprising to hear then, they've got great (not $1600 Dell HDR monitor perfect, but great) monitors. One of the core issues is constantly fiddling with the brightness, especially with multiple monitors. That's where ideally you'd want to have the brightness of the panel fixed, and change it with a lookup map, e.g. what f.lux does for color mapping at night. That's where you'd get ideal results, would be a…
You'd have to adjust both brightness and white balance based on the environment (just like a camera. How well do professionals trust the camera's automatic choices?) and probably the environment behind the screen (the rest of the user's field of view). And then you'd probably need to throw in an adjustment for the individual user's light sensitivity needs and preferences, and possibly the user's current eye dilation…
The per-application brightness should be done in software, and ideally take into account HDR and colorspace capability of the software.
Otherwise, like the user above had suggested, you have to switch brightness every time you switch between different programs.
In 88 (I was 19) I was a 'professional mac developer' and wrote a stack in hypercard to convert huge list of points to polygons, and split them with other polygons. The project was to split the parcels of land from Lille to Paris with the track of the TGV (high speed train) to calculate the expropriation the state was doing to the poor guys who'd end up getting their huge field cut in two, and would have to drive 20…
Earlier quoted context omitted.
Having used both, Scratch is nothing like Hypercard at all. Hypercard was very simple to start with, but you could produce properly powerful programmes with it if you wanted. A closer analogy would be to the fully featured Logos you could get in the late 80s which looked like simple drawing languages on the surface, but were actually pretty full-featured LISP implementations.
Agreed, totally different things. Hypercard was for sharing hyperlinked information. Scratch is for teaching kindergartners how to program in an object-oriented fashion.
Earlier quoted context omitted.
Actually a typical rant on Android development forums is how Google doesn't follow their own Material designs.
Maybe. Still, I go to material.io and I don't see anything there that would make those things better. I wish there was a UI philosophy that would take Tufte's ideas as a set of core principles: maximizing data-ink ratio, minimizing junk, increasing data density.
Wouldn't that just be Tufte's ideas? What's missing for it to be a 'UI philosophy'?