This takes too many design cues from so-called "modern" web and mobile apps. What's with the lack of scrollbars in all the windows/dialogs? I can't tell that content has been truncated when a dialog opens up with the overflow ending on whitespace between two elements. There's also no fade or shadows, so everything is just suddenly cropped where a window ends. It's not even clear which elements have their own viewports and which are scrolled together (so I missed extra elements in the settings toolbar/toolbox on the left). All the windows open up very small (too small to fit their content) even though there's room for bigger.
The lack of scrollbars on desktop is a modern trend that annoys me
Desktops aren't short of width, so why try and hide the scrollbars all the time, but programs seem happy to pack everything into navigation bars at the top where height is limited.
Your touchpad or mouse wheel doesn't tell you where you are in the document. Your touchpad or mouse wheel doesn't allow you to immediately, without any delay, go to the start or end of a document / list / etc., and Home/End keys are often not accepted by modern touch-oriented interfaces to allow for it. Neither your touchpad nor your mousewheel allow precise and quick navigation to a specific point in a long document. All of these missing features make me frequently feel lost in modern UIs.
What about “middle”?
That’s the point of the bar, you can go to any place with a click. And you can see where you are.
PC monitors don’t lack width, these changes ate just blindly applying mobile trends to desktop while disregarding their differences.
Theres is much innovation to be done in desktop UI design, but blindly following mobile is not the way. Mobile screens are usually smaller and have the opposite high:width rate, and you use touch vs mouse+kb. Different design patterns should apply.
Removing scroll on mobile makes sense, few usage on a very limited width. On desktop width is a commodity that is mostly left unused.
My XPS might as well not because they're placed horribly, MacBooks don't, and my Chromebook doesn't have the physical keys but maps them to hotkeys that some applications use so the behavior is inconsistent. My tablet and smartphone keyboards also don't have a way to send home/end with their native keyboards.
Didn't know that, never came accross one. Not sure I understand the reasonning about adapting an UI for shitty hardware though. Vote with your wallet damit.
In some programs those keys will move the cursor to the start/end of a line of text horizontally (text editors, web browser when you type in a form, etc.).
It's annoying on phones too. I have a modern phone with a small display, and I've occasionally missed options in dialogs because of zero visual feedback that there is more content.
If I'm lucky, then a line of text will be half cut off and I can tell that way. Otherwise it's impossible.
> I find window title bars to be a waste of space.
Here's a possibly controversial take: why couldn't we do the opposite of mobile "notches" but for the elements of title bars that actually matter?
So instead of having 20% of the window width be taken up by the title (which might as well act as a draggable window handle or allow opening window menu) and another 10% by the action buttons with 70% remaining empty, why couldn't we simply cut out the 70%? Sure, that might complicate the UI of some apps and you'd certainly need to consider how to not create awkward layouts (allow the titlebar to automatically be hidden until hovering over the edge of the window, like some panels do at the edge of the screen in XFCE and other *nix DEs), but surely we can have the best of both worlds?
Actually the elements popping out upwards is a pretty good approach as well!
Now, it might be a bit problematic when the windows are aligned with the top of the screen (in which case either the window would need to be moved or the title elements would just overlap the contents and be expanded downwards, much like tooltips would).
But yes, that's definitely one way to go about it!
That's basically what apps like Chrome that have "no titlebar" (at least on macOS) do. They incorporate the title bar controls into the window itself which allows them to render other things (like tabs) on the same row.
It’s inherently non-standard/non-unified though, and requires each app designer/developer to figure out how they’re going to do it (or more likely, how they’re going to screw it up). A slim, system-provided title bar avoids all that. Seems like a small and very acceptable price.
You’re joking about the lack of a title to tell you the name of the app, but not knowing which window has focus (thanks to titlebar shading) is a real problem. Microsoft completely disabled the coloring of the active window in Windows 10, then caved and re-added it as an off-by-default option. I can’t live without it on.
Well, in my admittedly limited experience of Windows 10, sometimes windows that look active, down to the blinking cursor, don't actually have the focus. So if all windows look the same, maybe people will get in the habit of clicking 10 times where they want to type, just to be sure.
I'm thinking mostly about the UAC window asking for a password.
I don’t understand why you’d want to risk typing into the wrong window or add such a cognitive burden (“where is my pointer now?”) with every keystroke rather than have the window that receives keyboard input be very clear and consistent. At least, as a heavy keyboarder, that’s how I see it.
Windows 10 oddly introduced focus-follows-mouse for scrolling (scroll wheel or touchpad) but keyboard input remains directed to the last-clicked window/element. It’s not a bad compromise (because primarily keyboard-centric users might not care where the mouse is and it lets you do things like scroll a background document for research while typing in a foreground document without losing the focus so long as you don’t click).
Agreed with the scrollbars - they should absolutely be there. I would also like to see a light-theme version, at least I need to squint a lot more with this dark theme.
I am extremely excited about Dahlia and the work your team is doing. HN has a significant cohort of people who are extremely opinionated about how OS UI/UX should work. Don't take that to mean there aren't people who are interested in what you are developing; keep us abreast of your progress and I will make sure to repeatedly check up on your subsequent developments.
Seems like around Windows 95 was the last time designers put a thought to designing for usability and around the actual constraints in the medium.
Most modern UIs seem to focus almost entirely on clean aesthetics, usually mindlessly drawing on conventions that serve limitations that exist in mobile, such as being really conservative about using screen space.
I think desktop Firefox is an excellent example of this. A lot of very useful features are hidden behind an additional click on a minuscule ≡-button (What does that symbol even mean? Why doesn't it have a label?) All, it appears, to save hundreds pixels of screen space, while desktop displays are getting bigger and bigger and bigger. You can't even use full screen windows on many desktop displays, you'll get neck pain from literally having to turn your head to read.
How many times do you really use that ≡ "burger" menu button of firefox in a day really? And after how many times do you end up having learned the keyboard shortcuts?
There are only a handful of them that don't have a keyboard shortcut.
afaik ctrl+shift+b show/hide you the bookmark toolbar.
I think there is none for the ≡ menu nor for settings* which is sad but most submenus are covered. I actually wish I could unmap or change the inspector menu shortcut (ctrl+shift+c) as I often use it by mistake if trying to copy/paste stuff from browser to my terminal.
* I actually do ctrl+t then type pref and find preferences in the history usually instead.
Honestly, maybe I just don't get design, but if having to use a search field to find basic features in an application isn't just resignation as an interface designer, then what is?
For a feature you use once every other week/month I don't see it as a resignation.
Don't see the point from a UI perspective to show me everything, including features I may never ever use, each time I want to access features used on a more frequent basis.
Don't you think you would use them more if they weren't hidden behind a menu within a menu behind a tiny button that's almost impossible to click because it's so small?
Right, but my point is this: What is the point in saving some sub 1% of screen space from a screen that is typically too big to even be fully utilized? Why are all the buttons tiny and hard to click, why do they have hieroglyphic symbols with no labels?
A button for opening an ad for a third party app (Pocket) is important enough to be immediately accessible. Why aren't my bookmarks deemed as important?
Makes a lot of sense on a mobile device where screen space is very limited. But on desktop?
The Win95 UI was the result of pretty thorough formal-ish user studies. How many design iterations after that went through the same process ? Fairly close to 0 I believe.
Not this reader. I thought W95 looked clunky in ‘95 and hasn’t aged well.
I much prefer the “open-ness” imparted by macOS’s border-free designs. It’s not perfect, and the “low colour, transparency in meaningless places” direction its taking isn’t its best look. It was better when it felt more “fun”.
I yearn for someone to take the pre-lion design goals and take them deeper i to more usable and more inviting directions.
Can someone give a little more information on what dahliaOS[0] is?
It seems to be the OS that has created this desktop environment, but the website for it doesn't seem to go into much detail. How is it related to fuschia? is it a google initiative, or something simply targeting the open source bits of fuschia that have been released? (there are some links at the bottom of that page[0] that sound like they'd answer my question, such as "the goal" but they all just seem to link straight back to the top of the page.)
I agree. Every Flutter app I've ever used has been noticeably janky. The absolute worst is the UI for the Google Home Hub which runs at about three frames per second and is incredibly unresponsive to touch and button input. It's as frustrating to use as the touchscreen navigation system displays in old cars, the ones with resistive touchscreens.
I like a lot of things about Flutter, but how did they develop a completely new UI framework from scratch in 2015 and not make fluid animations and fast touch response latency an absolute priority?
I interviewed with one of the flutter engineers. After a casual talk with him on how they were doing the rendering, while interesting, I had a feeling that fluter will fail. It reminded me a bit of all the HTML 5.0 on mobile efforts back in 2011-2014, which mostly failed. (React Native, was an offshoot of those earlier efforts, but even that is being slowly abandoned by the industry now).
That's what you get your company hires only leetcoders.
Sometimes domain expertise comes at expense of general expertise. (some people are super strong in one area, but not so in others). Google hires generalists, which are good at the small leetcode style problems given during an interview, but which surprise surprise are not super strong at design well thought out rendering techniques.
Hence the continuous failures in many new products.
It may have something to do with the fact that Flutter state management of the UI requires the UI to repaint completely whenever there is a change.
This makes no sense whatsoever because it goes exactly in the opposite direction of optimised graphics programming - where the ideal was to repaint the smallest portion of the screen as possible for any change.
No, that's not right. Optimizing repaint rectangles is kind of a corner case these days. It's a nice feature to have in some cases for reducing battery usage, but if you're relying on it to hit 60 FPS then you are certain to fail because there are always cases where you do have to repaint the whole screen. If you can't do that at 60 FPS you're already screwed.
Games redraw everything every frame, and yet good games have much better performance than UI toolkits generally.
Just curious but isn't the whole point of using techniques such as double buffering meant to reduce the time it takes to make an update to the screen? wouldn't that actually enable higher FPS? Why would you draw an entire screen when you could repaint just a small portion of it?
Double buffering prevents the user from seeing a half painted buffer. Instead of having the application draw directly to the screen buffer, the application draws to an offscreen buffer and the buffers are swapped only after drawing is finished. It's orthogonal to whether you do full or partial updates. (Although if you do partial updates then you're not really swapping the whole buffer, you have to do a blit to present instead and that can actually be less efficient than swapping if the swap path is really swapping, say if you're in fullscreen exclusive mode or if hardware overlays are in use). And it can only ever increase the time it takes updates to reach the screen, not decrease it, since it adds an extra step (swapping) compared to drawing directly on the front buffer.
Why would you draw the entire screen? Well, it instantly eliminates a whole class of bugs where partial updates don't match full updates. It eliminates a ton of really complex code you'd otherwise have to write to track the on-screen size of arbitrary changes separately from painting them, and skip things outside the dirty rectangle while painting. And it doesn't change your worst case performance, which is what you care about when trying to hit a fixed frame rate. Actually the worst case performance should be slightly better because you're not wasting time tracking changes when you have to paint the whole screen anyway.
So the question really is, why would you bother to implement partial updates? The only real reason would be to save power in scenarios where only a small part of the screen is changing. Which is important but not that related to responsiveness or animation smoothness, which again are about worst-case performance.
Even if you do want partial updates you may be better off simply special casing a few common things like blinking cursors or video playback than implementing a fully general change tracking solution.
Can you share your computer specs and what browser you're using?
It's buttery smooth on both my Windows desktop and Mac laptop, though both are relatively new.
On my 5+ year old 1.1GHz MacBook it's still entirely usable. Dragging windows around isn't entirely fluid, but it's not that bad for such an underpowered machine.
I'm on a 2019 16" MBP 2.6GHz i7 with a 5300M. This machine isn't a powerhouse, but it can drive 1080p240Hz + 1440p144Hz buttery smooth for a million Firefox tabs and a couple IntelliJ projects (if everything's all indexed...). On this site, I get like 10fps while doing things, clicking, moving around, etc. It doesn't even look like motion. I threw it into Firefox's profiler and it has consistent "janks" between 100ms to over 200ms. No thanks.
Perhaps we have different ideas of what constitutes "buttery smooth". I find the performance usable but sluggish. I think many people have become accustomed to this kind of performance though. Regardless, I find the design of the UI quite appealing.
Yes, I have a recent and powerful GPU with hardware acceleration enabled. I also tried this on my Windows box (i7-9700k, Nvidia GTX 1070), and if anything, it performs a little worse than my Linux box. It's definitely usable. I just have a low tolerance for sluggish software.
Just another data point here: I'm running a relatively high-end workstation on Linux/Fedora 36, and it is quite smooth in Chrome but somewhat sluggish in Firefox.
I worked on a proprietary trading app using flutter for mobile and we had zero issues whilst rendering both ticker prices and charts in real time. How is desktop so different?
5950X, 32 gigs of RAM, Win10, Firefox 98, 3080Ti (if it's GPU accelerated, I didn't look) and it's super jittery for me. It's usable, but it's not smooth at all. Dragging windows around is pretty bad.
I'm on a Framework running Arch with a 165 Hz external monitor, using Firefox, and it feels sluggish to me. It's usable, but feels like the performance I'd expect from a website. For example, grabbing a window and thrashing it around, it noticeably lags behind my mouse cursor. Resizing a window from the top is pretty bumpy. It lags behind the mouse and the repainting stutters.
You should try brave or chrome it's pretty smooth for me on a 5 year old Ryzen 1 system with 32GB memory. I don't even remember what my AMD card is, it was a mediocre card 5 years ago whatever it is.
Probably a case of having hardware acceleration turned off in the bowser, which at least for me is necessary due to issues with casting chrome windows in things like discord.
It's also perfectly smooth for me on Firefox on Linux, although my hardware is pretty performant (Ryzen 9 5900X), although normally Firefox detracts significantly from performance.
Current machine: Edge (closest thing to Chrome that i have apart from Firefox) or Firefox, Ryzen 5 1600, RX570.
The performance is passable for a graphically intensive application but entirely unacceptable for a desktop environment of any kind. In addition, it seems like it is a bit worse optimized on Firefox than it is on Chromium based browsers.
Opening 1 window and dragging it around leads to ~25% of the GPU usage (albeit i power limited mine to 50% of the total capacity), which feels insane when you consider that games running at 60 FPS use maybe ~50%. Opening up more windows, anywhere between 5-10 and dragging them around yields a similar load to rendering tens if not hundreds of thousands of polygons on screen.
Thus, i have to agree with the folks that say that this is entirely unacceptable as a desktop environment for any device, apart from when you are inclined to waste your hardware resources for no good reason. Admittedly, Flutter is better suited for this than it is for web development (in which it can be downright hostile and cause accessibility issues) and if nothing else the UI looks good, but personally that's not something that i care about.
In summary: i don't think that this would ever be an acceptable desktop environment, especially for devices that are running on battery power. Its resource usage would cripple any graphically intensive tasks in the background, unless you have really powerful hardware, which isn't the case for much of the world. Then again, in my eyes the perfect DE is somewhere along the lines of XFCE/LXDE/LxQt, so YMMV.
Edit: tested it out on my notebook as well, which has a N4000 Celeron and Intel UHD 600 integrated graphics. Even opening 1 window lagged everything considerably (on Firefox) and i have to guess that the FPS was somewhere between 10-20.
So, once again: unacceptable as a desktop environment, even with any given browser overhead. Of course, being able to run software like this in the browser reflects positively upon its portability, if nothing else, which is cool to see.
I wonder where we could get benchmarks that compare the low level rendering performance of the web vs native targets per platform. Having something like that would probably be immensely useful to be able to reason about the differences between them.
On both my Windows laptop (Ryzen 7 + 1080Ti) and Windows Desktop (Ryzen 9 + dual RX 5700 XT) machines, it is really slow. Dragging windows is unbearable and the other apps are quite laggy (such as switching views in the "media" app). Both have hardware acceleration enabled.
On my Windows workstation with a Ryzen 5800X and an RTX 3080, it is a stuttery mess on Firefox. Dragging windows happens at maybe 10 FPS, and there's half a second of input latency on everything.
My first impression upon opening this was about how fast and responsive this feels (chrome/linux)... Which actually now makes me more concerned that this experience is not consistent across users and platforms, because this leads to the dangerous "but it works for me" attitude.
Flutter has some performance issues on the web but it's much better when running natively. There's still some jank caused by shader compilation but they have plans to fix that. It's not inherent to the design of Flutter - it's actually an issue with Skia.
That said, I've only used it for smallish apps. Would be interesting to see how it works for a whole desktop.
My windows machine can run make and gcc natively. You don't need to be unix to run those platforms. I haven't watched fuchsia closely (last interfaced about 6 years ago, talked to a team member, who said that eventually it would be able to emulate unix enough to build and host a compiler).
I guess I should have put my question in a more useful way: why would I want to use this desktop, given its limitations compared to existing desktops? Is it ever going to be a development system? If not, I can't see how it would grow beyond being a device environment- in which case there probably shouldn't be a terminal anyway. Probably I'm asking for something which is not a goal of fuchsia, but in that case, I really can't get exicted about something that's supposed to replace Android and other OSes.
Very exciting. As this works on Fuchsia, a capabilities-based OS with a security-first design goal, is there any writeup on the security architecture for this project?
Is it correct to say that a convergent desktop environment exposes a large surface area via monolithic access to the underlying OS? It seems that the desktop environment is one of the hardest things to build securely, if embarking on such a journey.
Also, somewhat related: In light of forthcoming capabilities-based hardware (see: ARM Morello), is it a bit hasty to embark on a security-first rewrite of the entrenched Von Neumann / Harvard basis for incumbent OS environments?
Design language looks very similar to Windows 11? Not sure if it was intentional since it must have been in development for a while. Anyways, it’s a very elegant looking environment.
I'll agree—it's elegant. The animations are a bit "Flutter-y" and I'm not a fan of Flutter animations in general, but it does look quite nice: https://web.dahliaos.io/.
Looks very nice, but what is like more is a DE that is concrete stable. I've been told by people across the internet that I need to try DE #36 and that it's actually good, or that Gnome is awesome now.
They're always at least broken enough to impede a bit. I use Gnome now, but after my machine has been on for a few days, all text associated with the Gnome shell disappears and only comes back on restart.
MacOS works pretty well in my experience, but I don't want to be part of that ecosystem. Windows GUI is fine for the most part in my experience, but I want to use a Unix (WSL is good, but not a replacement for me).
For now, I'll hold out and keep rooting for the Linux desktop, but it's got a ways to go. Can't blame them though, Apple and Microsoft have tons of money being concentrated into a single GUI environment. Linux has a million different small projects paid for with some dedicated contributor's time.
I am surprised with your Gnome issues. I am running Ubuntu 20.04 with the stock Gnome and restart only for the kernel updates. It is my daily work system and I just put it to sleep at the end of the day.
My issues on Linux are normally always coming from non open source software (VMware, Zoom, ...).
What I found helpful is to do a full reinstall of the OS instead of an upgrade and carefully bring back the "dot" folders with my configurations.
I can absolutely agree with non opensource software being the worst experience on Linux. I can't blame the companies for not spending less time and effort on the Linux versions due to the percentage of their users that use those platforms, but it's unfortunate as a Linux user.
One of the things that makes me actually use Electron programs is that they usually work fine on Linux out of the box (sometimes there are deficiencies if it needs webcam/mic usage). That said, I hate having to hand over a precious few hundred megabytes of RAM on an old machine just to use a messaging app.
I took a quick look at the repo and the most important piece of info is missing: why?
What's the point of this project? More generally, open source projects should really get into the habit of spending a few words on WHY they exist, so people driving by don't have to wreck their brains figuring out why would you care.
It's a beautiful desktop! The animations are pretty janky though, at least in the online demo. This is a performance issue I've seen with Flutter before, so there might not be much you can do, unfortunately.
Flutter for Web feels incredibly sluggish and drops frames whenever I do any interaction. I’m not sure why that’s happening when most of the WebGL and WebGPU demos run at high frame rates.
Personally, I think GNOME has more polish than this—the margins are correct in GNOME applications (eg. in the "Search settings" text box in the Settings application). GNOME typically doesn't have those kinds of issues.
Gnome is a UX mess, everything is huge, zoomed, desktop screens have more WIDTH then HEIGHT, and yet they waste a shit ton of HEIGHT and force us to constantly have to scroll to see more content
Not even macOS went this far, Apple made the right call to develop a separate ipadOS, specific for touch screen UXs
"Do your research" coupled with unsourced assertions is always an interesting argument :)
As the product lead for Flutter, I can assure you that this isn't an accurate statement. The product is several years old now, and we only added ads support in the last three months, in response to customer requests (https://github.com/flutter/flutter/issues/12114).
Flutter is open source, welcomes non-Google contributors, and is led by a group of hackers who think that UI development shouldn't be as painful as it is. One might have thought this would be attractive to the kind of developers who hang out on HN :)
I think to say that its entire existence is a conspiracy to replace the web is a bit much, and I'm sure that the engineers creating it have good intentions. But that doesn't mean Google, the business, doesn't see the value to its bottom line. Google is and will always be an advertising company. Flutter may make UI development less painful for developers, but it takes control out of the users' hands. The web is great, despite painful UI development, because as a user I can adjust it to my liking, namely remove advertisements, tracking, and other annoyances.
AMP was supposed to speed up the web for mobile users. I'm sure the engineers that worked on AMP believed they were doing that too.
Certainly Google sees value in Flutter, otherwise we wouldn’t fund it to the tune of 100+ engineers. But our motivations are less malevolent than you might assume. Here is our strategy doc, which we publish in the open (not many products can say that, I think): https://medium.com/flutter/flutter-in-2022-strategy-and-road...
I read your strategy doc, and it doesn't change anything I said. Front and center is your commitment to developer experience, which is great, but what seems woefully absent is consideration for the end-user. I'm sure that you'll eventually get around to things like accessibility and bring them up to par with what we already have. It's worth saying that nothing should be built for production using Flutter until that's taken care of, but enough people have already said it.
What's absent is a commitment to empower end-users in the same way that the web does now. Your doc puts the developer front and center, but "developer" can be read two ways: the person writing code who wants good tools that make their job a delight, or The Business that wants tools to enable them to deliver products that the end user cannot open open the hood and tinker with. A consistent UI toolkit that lets you develop once and deliver to six platforms is great for the coder, and if in the process it just so happens that the frontend is reduced to indecipherable pixels that can't be modified, ads that can't be blocked, and tracking that can't be escaped, well, that's just perfect for The Business.
I don't doubt you or your team's sincere good intentions. I really don't. But after pulling stunts like AMP, Tag Manager, FLoC/Topics, etc. Google, the business, doesn't deserve a charitable interpretation. It's like Prisoners of Geography. Google is an advertising company, and always will be. Regardless of the ideology or stated goals of the day, everything they do is to sell ads. If Flutter allows Google to display more ads and collect more data, and Google is funding the development of Flutter, it stands to reason that Google is purposefully pushing Flutter because Flutter will allow them to sell more ads and subvert user privacy.
There's also a great Flash-like vector-based animation designer called Rive, which is itself written in Flutter (and generates code for Flutter): https://rive.app
Not OP, and can't comment on Google's hidden intentions, but it does have a point - any such open source Flash replacements would make ad blocking harder.
(All tested on the online demo here: https://web.dahliaos.io/#/ )