611–620 of 641 posts
Earlier quoted context omitted.
I think the filter used to be the cost.
Children were often more tech savvy than their parents, yet they didn't have as much to spend.
Also this was always kinda of a myth often.
Earlier quoted context omitted.
No. I worked with designers who designed low contrast and low density interfaces. I read articles written by designers. I used products of companies like Apple.
Examples? Are they interface designers? Are they qualified? The existence of shitty designers is no more an impeachment of any design field or designers as the existence of shitty developers is an impeachment of development or developers.
Earlier quoted context omitted.
> wildly impractical - there are only so many developer hours available Which is a huge reason that learning a RAD (rapid application development - emphasis on rapid) tool is a pretty useful skill.
What makes it rapid is taking shortcuts. There's no silver bullet for increasing speed while preserving maintainability and extensibility. Prioritizing speed is exactly the problem described in the post you're responding to.
I'm not "prioritizing" anything. The scenario we're discussing is when an intern or low-level employee is able to successfully automate, enhance, or simplify a manual, inefficient business process that management has not seen fit to improve - so the worker does it themselves.
Access and similar platforms aren't "rapid" because of shortcuts, they are rapid because they are visual-based, drag-and-drop, object-oriented and often make a component's properties and methods customizable also via a visual interface. It's a different way of programming, yes, accessible to the masses (which is likely the reason you have so much disdain), but not "shortcuts".
Earlier quoted context omitted.
We could do this. And if you take a look at some solutions like the old VisualBasic/Delphi/Unix scripts, the philosophy is the same: Create small software quickly that solves some user/business needs. Systems like Java/.Net and their IDEs, as all as current mobile SDK, they run against that need. A bit of tangent: I think the idea of coddling users is what’s leading to the complexity of all those system. We’re buildi…
Well, except you end up with 20 different incompatible tools with different workflows. I'm not really arguing for mega-tools with locked-down workflows. But there's usually some happy-ish medium between chaos and rigid monoliths.
Kinda the whole goal behind (and "benefit" of) microservices, right? Totally independent dev teams, all uncoupled from each other, no need to look inside at the code, language-independent - just pass data according to an API and dont look behind the curtain.
Earlier quoted context omitted.
> too many people consider it "perfect" and don't even consider discussing issues and complaining about things. That is becoming less and less true. More and more of the most ardent Apple fans have been complaining about the direction of macOS for years. Developer sentiment is low.
I've been a huge Mac fan for a decade or more, at least, and not only is Tahoe the least popular release I've seen, it's the first one where the majority of people I hear from dislike it. It's bad enough that I haven't updated still, I'm waiting a few point releases at least to see how they fix it up, and I'm trying out Linux distros to see what I'll start using if I have to move away.
I had to return that Mac for a screen defect, and the one I now have has been kept back on Sequoia, and I'm totally fine with it and will probably stick with it until security updates stop, at which point I surely hope Tahoe is more readable.
Earlier quoted context omitted.
Actually I think this is a killer use case for local LLMs. We could finally get back to asking the computer to do something without having to learn how to string 14 different commands together to do it.
I’ve been computer touching since the mid eighties. Exactly what golden era of computing are you harking back to, and what are you doing that requires 14 different commands?
Earlier quoted context omitted.
Ideally you'd want to add selectable options for users in a way that's sustainable long-term and not just panic-adding things all over the place because of user demands. That's how you get the Handbrake situation that OP article is complaining about. Gnome 3 was a big update and adding options, which does happen, is not free. There were changes from Gnome 2 and 3 and adding some options "back" from Gnome 2 is really…
> That the Gnome team has different priorities from other DEs, one of them being "keep the design consistent and sustainable," is completely valid and preferred by many users like myself. A new design metaphor can be "completely valid" and simultaneously an aggravating rug pull if it is pitched as a new numbered version of an existing program---especially an existing desktop environment that many people use daily---r…
I guess I agree? I never used OS X and actively avoid MacOS post-2013 partly because of the layers of inconsistency each new version introduced (when I used a Macbook, there were about 4 different "overview of current running apps + method to launch new apps" interfaces, accessed from one hotkey, two separate mousepad gestures, and a button in the UI, respectively.)
To my tastes these days Gnome Shell and associated GTK3/4 apps (see Gnome Circle), plus Flathub, are easily the most consistent and pleasant desktop app experience around. YMMV of course. (I'm the type who has never felt the need to mess with Gnome Tweaks, extensions, etc., if that helps.)
I don't run it (yet), but Fedora Silverblue is the future (for consumers running desktop Linux). I believe this in my heart.
Good article, but the reasoning is wrong. It isn't easy to make a simple interface in the same way that Pascal apologized for writing a long letter because he didn't have time to write a shorter one. Implementing the UI for one exact use case is not much trouble, but figuring out what that use case is difficult. And defending that use case from the line of people who want "that + this little extra thing", or the "I j…
Which is why observability is so damn important.
Observability allows you to grock what your users in aggregate are doing, and adapt your product accordingly. You can take the lower-40% of features and squirrel them away off the main UI. You can take the lowest-10% of features and stick them in a special tools panel that needs to be explicitly hunted down and enabled. You can carve the UI up into three different levels - focused, simple, expert - that hide certain functionality and features, and explicitly expose others in certain ways, and allow the user to switch between them at will.
There is just so many ways that this particular cat can be skinned, you just need to collect the information on how the users are actually using the product. You just need to get permission in ways that encourages your users to participate.
Because without that data, you’re just stabbing in the dark and hoping you aren’t stabbing yourself in the foot. Or worse -- metaphorically ripping open your entire femoral artery by alienating the majority of your users.
Earlier quoted context omitted.
> contributors of free software tend to be power users or, simply put, nerds it takes both a different background, approach and skillset to design ux and interface if anything FOSS should figure out how to attract skilled artists so majority of designs and logos doesn't look so blatantly amateurish.
My guess is that, as has always been, the pool of people willing to code for free on their own time because it's fun is just much larger than the people willing to make icons for software projects on their own time because they think it's fun.