Totally agree. To this day, I’d say my favorite reviews were/are the ones written by the great John Siracusa. Now those were reviews! Here’s one example of his works:
Using Haiku as my main system for months and I’d say I’m ready to throw rocks at anyone who says that window borders are inefficient In my daily workflow I have Clipdinger replicant showing me the current clipboard contents, sound bar replicant so that I don’t need to do an extra click to adjust my volume, Filer replicant to drag’n’drop files directly from the Tracker below it and DeskCalc replicant for “quick math”, all in the place which would otherwise be wasted with any other desktop environment. Haiku’s window title bars are as efficient as they could be even without using stacking
I have often wondered if stacking highlighting when tabs overlap should happen after two seconds without any need to hold a key down, and if tiling highlighting should happen all the time… Users would find these things out organically then…
I was wondering (as I often do…) if we’re better off targeting a set of modern known hardware? For example, Apple don’t support any old hardware for OS X, but only their own.
If we deliberately targeted an affordable but common hardware provider and worked with those users to support specific laptop models for ‘modern’ systems, leaving older systems’ components for the BSD drivers to catch up with.
(As an aside, you could even sell preinstalled QA’ed laptops with Haiku, much the same way as pcspecialist.co.uk does with Linux laptops.)
Naturally we should totally start with my laptop! I can’t even get the live USB running though which kinda makes it hard to investigate… Just the KDL page. Already reported that.
Still getting some things like keyboard back lighting working in the Linux kernel. Once done I’ll work on Haiku bug tracing. Has common Intel hardware so fixing this laptop should help a lot of people.
Yes, but there is the risk of triggering it by accident when you were just trying to move a window around. Maybe show something next to the cursor while dragging windows to hint that some action is possible with modifiers? (a tooltip, basically…)
Maybe take inspiration from what Windows does when dragging files, IIRc pressing a modifier will show a little icon next to the cursor to let the user know what will happen (copy the file? move it? popup a menu asking what to do?)
That’s the problem. The only way would be to buy a few dozen laptops and give them to devs. But then, it just degrades our overall coverage of other machines. It is nice that Haiku is easy to try on any machine you have around, and quite likely to work. Look at what happened to ReactOS, they are stuck with this single 20 year old Dell laptop as their official supported hardware, which is not so nice.
Also, each of us have different need. I like a 12" laptop when I’m on the move. I also have a more powerful desktop machine, which eventually I rarely use because all my files and workdirs are on the laptop.
Linux-User.de did a review of Haiku, which is published in the December issue of the paper magazine.
Also readable online: http://www.linux-community.de/ausgaben/linuxuser/2018/12/haiku-os/
Personally, I think adding + to the tabs like Firefox or Opera did back in the day (and revolutionized tabbed browsing) would greatly aid tabbing discovery, so people interested in the UI and/or the OS itself could utilize it. I might open a topic on this soon to explain what I mean…
Nice read… very promising
That’s still a good idea though, for developers that are capable and interested, the purchase of a nice new laptop for them should be on the table. I’ve offered hardware recently as well but no one took a bite :/. I’d say as a rule if a developer wants a machine bought for them, it should be different from previously supported and purchased machines so that it promotes broad hardware support rather than limits it.
One problem is that often developers only have hardware that is rather old, so you can’t even buy a computer off the shelf that works with Haiku you have to resort to ebay etc… recent Intel hardware mostly works of course at least up to a certain point, but all the recent AMD hardware which is affordable and fast, has major issues.
I’d still be willing to ship out a Ryzen x370 motherboard + Athlon 200GE to anyone that wants to get Ryzen mobile working (this would likely enable laptops alsos since it’s the same chip as 2500u/2700u and 2200G and 2400G), also Ryzen 1xxx chips are cheap as peanuts now even for 8 cores they’d make excellent PCs regardless of what you want to use them for if only you didn’t have to enable the 4GB ram limit. Still have the RX460 cards as well for any developer that wants to support them, just add ram + PSU + case for around $200.
There have been a number of cases, mostly with systems introduced to markets within the last year, that do not even get to the Haiku splash screen. While many systems enter KDL, others simply reboot - without providing much information as to the cause of the crash.
The historic approach of having the boot loader sending output to the serial port mentioned in the guides is not really applicable as serial ports have essentially become extinct especially for notebooks.
Some thoughts should be given about an approach which would provide the information necessary to file a detailed ticket.
Do manufacturers have promotional programs in which notebooks are provided for development purposes - similarly to what is being done for reviews?
Even further, could a manufacturer be interested to the point of having a system pre-configured for Haiku? Yes, I am dreaming yet Project Sputnik aiming to be “a system developed by and for developers” has been successful with continued marketing of XPS 13 and XPS 15 “Developer Editions” with Linux pre-installed.
Would a networked BFS server be useful as a common synchronized share? Could such a thing even be implementable in Haiku?
Probably not until Haiku has a real stable release… perhaps a pipe dream even then.
Haiku already has netfs, which is the native networking filesystem… I believe it does support queries.
Maybe show something next to the cursor while dragging windows to hint that some action is possible with modifiers? (a tooltip, basically…)
Maybe showing some stacked tab ghost as an hint that the tab could be stacked there?
There is visual feedback when you are holding the window key already (the target tab or window border is highlighted). We need a hint that modifier keys are available, not a hint about what they do, maybe? Otherwise people would try to stack windows without a modifier key, which doesn’t work.
I remember from Linux infantile era a review of certain Linux distribution with Gnome desktop. The author pointed out: “First thing I did was to place the taskbar back to its place - the bottom of the screen”, where “its place” meaning “usual for me as a Windows user”. Gnome always placed the taskbar at the top of the screen. Nowadays Windows can place the taskbar anywhere and actually many Windows users do place the taskbar at left, right or top of screen. This is Gnome habit for Windows users.
So I believe, this is not so much a matter of “intuitiveness” or “discoverability” but rather a proper habit. Today nobody reads the docs to use the (non-intuitive) shortcuts Ctrl-C, Ctrl-X, Ctrl-V, Ctrl-Z, Ctrl-Y (or Meta-*), and expects them to work on all OSes and applications. Even Emacs, famous for its shortcuts, configures all these in 1 tick from menu. But for DOS era this was completely new (it was Ctrl-Insert, Shift-Insert, etc). Time goes and users change their habits and with it also their expectations.
I would add that while the QuickTour is certainly the OS developer’s task, the hardware drivers are hardware manufacturer’s task. This is true for each and every OS on the earth. And Linux hardware support is only as good as HW manufacturers provide drivers for it, all officially unsupported is a work-around.
Let’s not have a race to the bottom regarding assumptions on the user’s intellect and curiosity.
If the user is keen to try out Haiku on his/her own initiative (unlike someone writing for Distrowatch for example), then this user will be able to figure things out, accepting some thresholds that in this case are not too high at all.
If the user even considers reading the documentation to be a high threshold, then all we can do is make the documentation easy to digest. In a visual age like today that may mean producing short and clear how-to videos on YouTube for example.
Leave the dumbing down, nanny approach to MacOS and Windows. Don’t give indicators through pop-ups, tooltips etc. that may work in the very first use but after that will annoy everytime they become visible.
Well, I hate videos. I don’t know if we entered a “visual age” or something, but clearly not everyone like them. They are also difficult to search, difficult to skip boring parts, difficult to slow down when you want to spend more time on some tricky part.
The Quick Tour seems to be a good thing: showing hte key features and letting the user experiment with it at their own pace. Not too much reading. Easily translated to many languages.
And, this is not about “dumbing down”. Tooltips are annoying in either way: when they pop up and you don’t need them (argh, that “use lat enter to exit fullscreen” one in Terminal is one of the things I hate most in Haiku), and not really practical when you ned them (why would one hover all icons one by one to discover the one they want?).
But, there can be other kind of visual hints around the cursor or in other places to let the user know what actions are available. Something that doesn’t get in the way.
See the last two cursors here. They don’t get in the way, they are space efficient, but they help you know what will happen. This is not annoying, and helpful to everyone. I would like to find a solution like that.
Regarding discoverability for Stack&Tile, it reminds me of what Apple did when they introduced multitouch trackpad gestures, for mission control, launchpad, workspace switching and so on. They integrated short videos in the corresponding settings panel, showing how to use each gesture. This way, people could keep using the trackpad as usual, but they could turn on/off these new gestures, while having right there a visual clue of how they worked.
It was a simple solution for what would be a complex usability/discoverability problem.