This would 100% keep me from using this. a11y is my number one reason for using third-party UI elements. Making things work with the mouse is usually easy enough, but for complicated widgets there’s a long tail of subtle accessibility issues that are tricky to get right.
I mean I get it, but accessibility is one of those things that can be very painful to add after the fact. If this project is meant to be used in actual applications, they’ve pushed a very tedious task unto outside contributors.
This is a fine and good statement for many things, but a11y is more of a fundamental architectural & design consideration for projects of this variety. In my experience, a lack of a11y consideration overall is more of an indicator of the overall suitability of the product design for your needs than simply a "missing feature you can add".
Open Source software is great insofar as you can contribute to it in many ways, but applying this logic to all situations is really dismissive. There are many aspects of software projects that are largely or solely dictated by the creators/maintainers of that software, that may be impossible for idle contributors to significantly affect (and even forking can be a gargantuan/unviable option in some cases).
TL;DR: Open-sourcing your software should not shield you from constructive criticism, NOR should it invalidate the advice of informed people recommending against using your software.
The fact that "anyone can add a feature" doesn't excuse the lack of a feature existing _right now_, especially considering (as other commenters point out) accessibility is very difficult to retrofit. Not to mention, accessibility should be a top priority for any user-facing software, and the fact that it was utterly neglected suggests there may be other basic flaws.
I think the parent tried to make a point for accessibility. For example if you were a blind person browsing the web through audio, you'd wanna know which items are focusable.
...that's in development. Professional things are not allowed to be in development?
Do you go around your town criticizing people that are in the process of constructing office buildings, because they don't have the wheelchair ramp installed yet?
Perhaps if you care so much, you can lend a helping hand...
This isn't a case of having a wheelchair ramp that hasn't been installed yet. This is more like there's no wheelchair ramp, and while there's room for one out front, they've already done the landscaping there.
How does the analogy break? Do you think you can't tear up landscaping? To add a ramp you have to do work to undo the existing landscaping, install the ramp, and then redo the landscaping in a way that fits with the ramp.
And then pee on the floor and do jumping jacks, run in circles, then read a magazine, then install an upside-down lectern in the living room only to realize... you forgot the television.
The analogy breaks because code is able to be changed at any time almost as easily as writing new code. There is no such thing as landscaping in code. It's all easy to change.
You seem to think that it's completely free of effort and cost to change code. That is absolutely not the case. Some things can be incredibly difficult to add in to a codebase that wasn't designed to expect that kind of change.
> Some things can be incredibly difficult to add in to a codebase that wasn't designed to expect that kind of change.
In a 3 week old code base? Please... You can write the entire thing over again in a week and add what you want during that time.
The commenters here should do that too! It would probably take less effort than bitching about someone's side project that they'll probably never even use here on HN.
Tearing out code that has already been written (which would be required here) is analogous to tearing out landscaping that has already been installed. You either don't understand accessibility, analogies, or both.
How hard do you think it is to dig up some flowers? This has become a pointless discussion, and you've obviously got an axe to grind for some inexplicable reason, so I'll leave you to it.
This part of the discussion has definitely been pointless since the beginning, when people came here to complain about that on some guy's side project which they'd most likely never even use.
If anyone's got an axe to grind it's quite obviously them and you.
We've changed the title from "Show HN: WinBox – just like Windows, but for the web". The "just like Windows" thing was baity and provoked complaints.
Also, "Show HN" implies that the project is your own personal work. If that's the case, let us know and we'll put it back. But if it's not the case, please read https://news.ycombinator.com/showhn.html and only put "Show HN" on your own projects.
[Edit:] I'd try to make sure that, in the title, it's clear this is an in-browser library.
I honestly thought this was a window manager, you know, the piece of software on a desktop OS that draws the windows. IE, I thought it was a window manager that made it easier to use web applications on a desktop computer.
It took me awhile to realize that this allows desktop-style windows inside of a web browser. Not really a "window manager."
Ok, I've changed it from "WinBox: Modern window manager for the web" to make that clearer. We usually take the word "modern" out of titles so I've done that too.
This looks fun. I wonder what kind of applications could benefit from a UI paradigm like this (virtual movable windows inside a browser tab). The only ones I have seen in the wild are demos (the one with winamp and the prank winXP one) and some limited compose/chat windows in Gmail and Linkedin.
This could work for things like Email clients or UI's like Owncloud/Nextcloud. Any app that wants to allow the user to juggle multiple actions at once.
When instant messengers like AIM, ICQ, Jabber, or MSN were in heavy use, there was a very popular web based client for those services. It used the same type of UI quite effectively. Here's a screenshot from 15 years ago: http://googlesystem.blogspot.com/2006/06/meebo-all-in-one-on...
Meebo was acquired by Google and killed off in 2012, when its utility was waning anyway.
Stock trading apps use UIs like this. I work with a couple these days, and they are surpringly well built, with movable windows, fast updates (every five seconds or so), alerts, charts, etc.
Not sure about floating windows (I don't like them much personally, so that might be why), but I've been toying with the idea of building a UI for a web-based database that would allow you to drag links onto the sides of "internal windows" or alt-click links to intelligently create a new window somewhere. Kind of like a tiling window manager, but just for one site. Since the devs would control all the UI code, they'd make sure it scales to very small sizes.
The idea was to make the common action of "opening multiple links from a list in new tabs" better, where tabs are too large containers and OS windows are often unwieldy. If you wanted to look at one of the results further in a bigger window, you could then pop it out into a new tab (again, kind of like tiling WMs with desktops).
@gwern's site[0] has tooltip popups, basically Wikipedia-like page previews on the rocks, that employ this paradigm. If you check some of their articles, they're very dense in content and sources/links meaning that having a quick way to check them works good.
MDIs (multiple document interfaces - https://en.wikipedia.org/wiki/Multiple-document_interface) are great for some desktop apps but they don't translate very well to the web mainly because you can't deep link to a window set unless you use something like a persistent session id that keeps track of the window state on the server.
This kind of came up for me in a recent discussion, as my team is converting a trusty desktop application to a web-based system. The existing app is fairly complex, and is aimed at expert users who spend a significant amount of time in this app as their primary workplace. They enjoy the kind of flexibility that resizing, rearranging panels can bring. Additionally, they love the current ability to grab a panel, tear it loose from the app window into a new window, which they can move to their 2nd monitor.
So basically, think of how an IDE tends to allow you to customise its UI to suit whatever task you're thinking of. Clearly, we can and will ensure that the main use cases have a compelling equivalent in the web version, but it's fairly intimidating to think that there's no easy way to offer these kind of expected features on the web.
Try searching for "docking layout" with a dash of "Visual Studio" (the drop target hints presented by the original, non-Code version are quite good at letting the user figure out exactly where the dragged window will attach).
One example is https://github.com/node-projects/dock-spawn-ts , but there are many more. Maybe you can also tease out the layout logic from VS Code or Theia (or even better, someone else might have done the work).
I'm on the hunt for a good package like this for react. I have been experimenting with https://github.com/ticlo/rc-dock/ and it's pretty awesome. I think the vanilla js version is probably nicer to use, though.
That's an interesting direction, and I'll keep an eye on it. Unfortunately in this case though, it's probably too far off the company's beaten track to use, as we have to integrate with plenty of other teams' work, which would be vanilla web+js stuff. While I'm sure it's surmountable, I'm not sure a hybrid is worth it.
It'd be lovely if Jitsi or other video conferencing systems let me move and resize other people's screens and cameras. I find a lot of the current layouts extremely suboptimal, expecially if a couple of people in the group don't have video or if you don't want to see yourself with the same prominence as everyone else.
One I can think of are scientific data searching tools. Where you need to compare things. Tabs make that somewhat complicated especially with JS heavy pages where links are just "javascript:..." so you can't open to a new page
This is very cool. Performance tip that I noticed on low-powered low-spec mobile devices: you maybe could try locking the text or removing it during window resize to prevent reflow, as reflow seems to be slowing down performance and stuttering the window resize animation.
Not with any reliability, as it is a subjective matter (different users will want to make the utility/performance compromises in different places) and even if you manage to smooth the subjectivity out of the equation there are other variables over time (if you test performance now and decide to use the full-fat function as the current device seems fast, heat or battery concerns might cause the device to slow right down in a few minutes time). Same for network related limits - your application could start while the device is on a wireless AP connected to a decent fibre link so have significant bandwidth and relatively low latency, then the user immediately walks next door out of range of that AP and the device resorts to whatever 4G (or worse) link is available in the area.
A better approach might be to simply let the user choose. At the start either default to one version (full fat or basic), or give the user a choice up-front, and make it easy to switch later. Perhaps do a quick test and warn the user if they pick the setup intended for high performance on a device upon which it might be slow, or recommend switching down if things get problematical later.
I'm not sure whether you meant guess from JS or just guess.
In the second case, reasonable, and "should be" and "considered" are all value judgment words that you will decide yourself if there's a fit for you. So if you meant how can someone judge a phone, you'll have to decide for yourself, because that's the only way you'll feel satisfied with your particular definitions of reasonableness, consider, and should. If you insist on discussing it with other people I think it would be an easy way if you wanted to spend a bit of time arguing about those definitions and which one you personally feel is right, or getting even more meta you could probably try to start a long-winded argument with people by suggesting that these words have no subjective judgment definition but are in fact truly objective. But I think all that's kind of pointless so of course I wouldn't waste my time arguing any of that. ;) ;P xx
If you meant, case 1, guess from JS, you can get the memory and the number of cores from the deviceMemory and hardwareConcurrency properties of the navigator global object. While i think that's probably not sufficient I think it's a start and you could always research more for yourself if you were genuinely curious about this.
If it's case two you don't need to be afraid to make a choice, just look at it and make a judgment about whether you think it's low spec or not.
Looks cool. Is the name a play on Blackbox/Fluxbox/Openbox? It's in a different problem domain so it's probably not a problem, but "Winbox" is also the name of Mikrotik's RouterOS configuration utility for Windows: https://help.mikrotik.com/docs/display/ROS/Winbox
Hehe, when reading title I thought: Is that a web based utility for configuring Mikrotik? But they do have Webfig that is quite similar to winbox: https://wiki.mikrotik.com/wiki/Manual:Webfig
IANAL but from a Trademark perspective, it might only matter that they are both software products. When we registered a trademark for our software in the EU, the application form only asked our industry (software development and consultancy).
It would be nice to be able pop-out a window (and set pop-out to the default) so that I can use the proper window manager built into my OS.
I don't think having an in-tab window manager is a bad idea. There are numerous sites that I like to keep contained in one tab, however for the heavy-interactive types of site where windows like this make the most sense I would generally rather use OS windows so that I get keyboard shortcuts, tiling, multi-monitor, snapping, always on top and all of the other features that exist in my OS.
I don't know if OP is apart of the org, but it's frustrating that when I maximize a window, and then minimize it, and then re-open it (holy this language is inconsistent), then it sizes back to default. This doesn't occur when you resize the window manually.
Why have multiple tabs when you can have several windows open and move between them?
I can see this being useful for an application in which the user needs to interact with multiple things and they don't each need a full tab/window (would in some cases be pointless in its own window). A chat application, or a monitoring system, perhaps. Or just when porting over an old desktop system to run in-browser with minimal UI changes.
It is like nested virtualisation. Why would I want to run a VM in a VM in a VM when the inner VM would be more efficient run directly on the metal? The answer is two-fold:
1. Generally, I wouldn't...
2. ... but for some niche use cases the facility can be very useful
> Why have multiple tabs when you can have several windows open and move between them?
Then... just open a new native window, like a normal person. You can still do it with modern browsers without incurring megabytes of JavaScript and performance slowdowns.
If the app is JavaScript heavy anyway, and it likely is if something like this is being considered, you have that all loaded into each tab/window instead of just one. Also you no longer have what might be small tightly coupled app elements contained in a simple tab where they can't get confusingly separated and where the app has to work harder if it needs some for control (a modal UI element being the most simple example).
Though I think you misunderstood what I was getting at with the tab/window thing. I was pointing out that the general "why X when you can Y" stated in the parent post isn't a great arguement, on its own, for not X.
This looks like it's targeted at webapp developers who want to use windows within their app. It does make sense for apps with a lot of modals, like an in-browser Gimp clone for example.
I've seen this approach being implemented (a lot clunkier, less polished and slower) in 2010-era stock market websites like https://tradingdesk.finanzen.net - essentially in highly-configurable dashboards that a user changes often (think: every few minutes.)
Indeed the website you linked to is laggy. But if it wasn't, do you think it's bad paradigm for such website? To me seems like it makes sense. How it compares to the more modern, polished, ones?
I prefer to tinker with code without a compliation step. So I made the demo work with the code in src/ to run without a compilation step. The demo is almost pure html/js/css but not completely. It uses webpack for the styles (pipes them through less) and the js. The js is plain js but the index.html expects a version that is de-modularized by webpack.
But changing a few lines index.html got me to run the demo with the default styles.
Kind of unrelated, but I find it interesting that I've only used 'let' a handful of times over the past 4-5 years and then I see projects like this where it's the rule, not the exception. Am I in a minority that thinks 'let' is a code smell?
No, quite the opposite - `let` should be used by default (due to better scoping rules (block rather than function) for most cases) and `var` only used when necessary.
To me, the code smell is the syntax from BASIC (and later C) that goes:
<code>
x = y
</code>
I've always disliked that notation; it looks like the statement "the value of x is the same as the value of y". So "let" turns the code into something that makes sense when read aloud.
Syntactic sugar is syntax that makes it easier ("sweeter") to do something the language can already do. For example, async/await is syntactic sugar for promises.
let isn't syntactic sugar — it's the only way to declare a reassignable block-scoped variable (as opposed to const, which can't be reassigned, and var, which is function-scoped or globally-scoped).
The way to redefine a const is to define an object who's values are mutable. I strongly prefer that as I can couple the mutating behavior in a single object.
The core problem with the BASIC syntax isn't the lack of a keyword, it's that stupid = sign. Assignment almost kind of means equals, except it actually totally doesn't, which is the absolute worst kind of resemblance. Oh, and now you also have to invent some other construct like == for actual equality!
I'm admittedly not sure what symbol should be used instead. I'd suggest <= except it reads as "less than or equal to".
A lot of JS in the wild favors putting everything in objects (maybe not explicitly, but they end up doing it a lot anyway) so gets away with a lot of "const" use that still lets them mutate the values of those objects. If you're dealing with primitives you're going to need "let" a lot more.
That is kind of my point, I don't often work with primitives that need to be redefined. I'd rather operate on an object where I can mutate its value rather than redefine the whole thing.
I was hoping it is like a remote desktop, but with web front-end so instead of pushing pixels it would push text, a bit of styling and media, maybe even some JS. Something like NeWS, but in a browser. Not necessarily WebX11, but that also seems fun.
I'd love to see MDI implemented in productivity web apps. Like all "cool new tech" (read "well forgotten and reinvented basic ideas") it will inevitably come into fashion in a couple of years.
This is amazing, well done! I'd suggest for the modal window you add that it closes (a) if you click outside the modal into the greyed-out area and (b) if you press ESC.
running movable and resizable windows inside a browser is neat but it feels like an antipattern. the top bar just seems like wasted space on a page, and it is distracting from the actual content.
The title of the link says "just like Windows". It's not an operating system API like Win32, and it's not a faithful clone of Windows's window management behavior, like your title implies.
I can't drag a window so it lies partly off-screen, instead the window stops moving when I keep moving the mouse, allowing the mouse to change position relative to the title bar.. I can't aero snap, nor "snap window to full height". Only minimized windows are visible at the bottom of the screen, not a taskbar of all open windows.
There's some additions not present on Windows, that threw me off. There's an full-screen button in the title bars, which confused me at first (but could be useful). And each minimized window has a maximize button, which isn't present on Windows and confused me. It seems that whether a minimized window gets restored or maximized depends on whether you press the button or not, rather than being remembered like Windows does.
Windows was a GUI shell on top of DOS, which this seems to be loosely alluding to. No Aero, no taskbar/superbar, no other features you're talking about.
Are you suggesting that only positive critique should be allowed? If I was the developer I'd love to hear that user's honest take on my creation rather than the "oh, cool!" type of input.
Surely you’re not going to make me spell out for you why comparing a little window widget in JavaScript with features of the Windows operating system, isn’t helpful just because there was a soft analogy in the title. Surely, you could’ve seen more than that dichotomy you presented me with before you made me write this. But here we are.
This sort of “critique” common on HN and it’s a toxic culture. Not all critique is good critique. We should be against crappy critique like this because it’s not helpful, it’s mean spirited, and it’s anti-maker.
At the time I commented to the post, it was marked as "Show HN: WinBox – just like Windows, but for the web", implying the submitter was the project's author making sweeping claims about the software. The title has since had "Show HN" removed (had it been like that, I would not have written my original comment that way), and the inaccurate tagline removed as well.
Arguably I tend to be not only perfectionist and detail-oriented (whether on important or unimportant details), but even pedantic, or quick to judge, at times. Nonetheless I do not appreciate being having my writing called "mean spirited" or a "toxic culture".
> Be kind. Don't be snarky. Have curious conversation; don't cross-examine. Please don't fulminate. (...) Please don't post shallow dismissals, especially of other people's work.
The show example "button" is a non-focusable div element
Once the window is open, the minimise, maximise, full-screen and close "buttons" are spans containing no useful text. The list goes on...Sure, sometimes accessibility can be hard to get right but it's quite something for it to have been completely disregarded.