Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

An experiment in UI density created with Svelte

cybernetic.dev

Post reply on HN
Print view View original

241–250 of 267 posts

Re: An experiment in UI density created with Svelte

#241

Post by __jonas »

malkia wrote: post #212
mst wrote: post #209

Earlier quoted context omitted.

Having found more than one thing called that, could you enlighten me as to which Houdini you're referring to, please?

Assuming it's the SideFX product - https://www.sidefx.com/ - it's simply the best in it's class.

I’m not super familiar with 3D stuff, but I’m curious what the “class” here is, is it specifically procedural sort of effects creation mainly for film?

I’m assuming for ‘regular’ 3D modelling people still prefer other software like blender/max right?

Re: An experiment in UI density created with Svelte

#242

Post by mrgoldenbrown »

wruza wrote: post #195
g15jv2dp wrote: post #123

Earlier quoted context omitted.

> This is not true. Mobile platforms do help with tapping on small elements. E.g. HN isn't mobile friendly "as is", but I have no issues with tapping any of the links. I've also used Exante mobile trading terminal for some time and had no issues with it either. Good for you, maybe your phone screen is huge. I routinely tap on the wrong element when using HN on mobile. Even on desktop I have to set the zoom level to 1…

4.7" iphone. They enlarge tap regions for tappable elements since forever, so you can’t miss.

If you have 3 tap regions already adjacent before enlargement, how does enlarging them help? Like the w, a and s keys on a keyboard. Making the regions larger will just make them overlap.

Re: An experiment in UI density created with Svelte

#243

Post by skyyr »

pavlov wrote: post #184

In my opinion this experiment is missing a key element of designing for UI density: typography. These screens use a fixed-width font at a single size. It’s a retro 1980 text-mode UI look, and it’s fine if that was the design constraint they wanted. But you can squeeze a lot more information on screen if you can have a proper hierarchy of typefaces and sizes. (As a basic example, the “About” box now consumes almost a…

Have a particular work by Edward Tufte to recommend on the subject?

Re: An experiment in UI density created with Svelte

#244

Post by hollerith »

hombre_fatal wrote: post #235
hollerith wrote: post #39

Earlier quoted context omitted.

>I wasn't expecting such unintuitive zoom behaviour. Huh. I expect user-interface surprises on web pages. Interacting with the other user interfaces in my life is much less surprising.

You usually can’t viewport zoom non-web UI.

I beg to differ. The most useful kind of zoom zooms the entire UI and this is straightforward to do on Windows and ChromeOS in increments of 25%. It is possible in Gnome, too, (again in increements of 25%, at Settings > Displays > Scale), but it is not straightforward because before you can do it, you have to say, `gsettings set org.gnome.mutter experimental-features "['scale-monitor-framebuffer']"` once per install of the OS.

None of them exhibit the wonky behavior of zooming a web page described above.

Re: An experiment in UI density created with Svelte

#245

Post by asoneth »

sulandor wrote: post #175
funcDropShadow wrote: post #148

Earlier quoted context omitted.

> I'm curious why you think it reduces design costs to put less information on the screen? The question is for whom it saves costs? For the developers of UI framework it certainly saves cost to treat the desktop as a second rate platform and to focus just on mobile. Developers of desktop applications have to pay the price, by working around libraries and frameworks that do not consider them as a first tier clients.

maybe oversimplified: things on screen take effort. less things, less effort

I've been a designer for a long time, and none of my contracts have ever paid based on the number of things I put on the screen. The design effort required to make a grid or list of data dense or sparse is pretty much identical.

(At least in enterprise software the data density typically depends on who makes the purchasing decisions. If novices and/or business folks are the ones making the pick then the software will look sparse. If technical and/or experts pick their own tools then it'll be dense and efficient.)

Re: An experiment in UI density created with Svelte

#246

Post by wruza »

mrgoldenbrown wrote: post #242
wruza wrote: post #195

Earlier quoted context omitted.

4.7" iphone. They enlarge tap regions for tappable elements since forever, so you can’t miss.

If you have 3 tap regions already adjacent before enlargement, how does enlarging them help? Like the w, a and s keys on a keyboard. Making the regions larger will just make them overlap.

Idk how apple does that exactly. I’d just voronoi it if they intersect and tap outside-ish, just like I do with hn vote arrows.

Anyway my point is that you can design interfaces denser than three buttons per screen and they will work. Not that a 5mm block with 8 links in it is a good button bar.

Re: An experiment in UI density created with Svelte

#247

Post by saagarjha »

ctippett wrote: post #37

On mobile, if I zoom out to 85% everything gets smaller and more things fit on the screen (great!). Zooming out further to 75% makes everything larger... 50% and things get larger still (more so than they were at their default size at 100%). The layout works remarkably well on mobile regardless, but I wasn't expecting such unintuitive zoom behaviour.

Are you on iOS perhaps?

Re: An experiment in UI density created with Svelte

#248

Post by Thro4l31 »

cranberryturkey wrote: post #187

svelte 4 is handsdown the best framework out there. I really am disappointed svelte5 is turning into react-ish framework. That was the main reason I used svelte was because it was NOT react.

> I really am disappointed svelte5 is turning into react-ish framework.

This is very wrong. Read the announcement and the docs: https://svelte.dev/blog/svelte-5-release-candidate https://svelte-5-preview.vercel.app/docs/introduction

Svelte 5 has change its reactivity model to signals. I anything, it's became similar to SolidJS. All other changes are minor but make Svelte even simpler to use.

Re: An experiment in UI density created with Svelte

#249

Post by Thro4l31 »

andrewstuart wrote: post #215

https://static.crowdwave.link/index.html Above is the evidence that react can handle this sort of thing just fine. I hacked/converted the page in question to React to show something similar. Its randomly generating updates to the table and then resorting the table and repeating. You can grab the source here but I warn you it's hacked together in less than an hour: https://static.crowdwave.link/sveltetest.zip

Of course React can handle complex and large scenarios. And those scenarios aren't even large. It's good that you created that proof. Still, Svelte is much easier while more performant, even if that extra performance is most often not needed. Large amounts of data can be managed by react-virtualized in React. IME Svelte (and Vue) can handle more without virtualization, but for really large data sets you need it anyway. The downsides of React are not performance IMO, but DX.

Re: An experiment in UI density created with Svelte

#250

Post by Thro4l31 »

solardev wrote: post #160
funcDropShadow wrote: post #151

Earlier quoted context omitted.

> Here's an example table with 100,000 cells ... > It seems fast on my computer normally (M2 Max), slow but usable when the CPU is throttled down 4x, and too slow after that. But that's a lot of cells. No, it is not a lot of cells in a table. It is something a Windows95 era PC had no problem doing in something like Delphi Builder. And you find it acceptable that it slows down, if an M2 Max throttles down? Even a thro…

I think all software is a balance of factors, from performance to ease of use to DX to maintainability, cost, etc. I don't think most tables need to be as peformant as possible, especially when a slow render is still measured in sub-seconds. That level of performance is totally fine for many use cases. If you have a special need for large datasets, yes, you should pay more attention to how that's optimized. But for y…

I think this all is true. No idea why the downvotes.
Post reply on HN