Comment by 201984
18 hours ago
>Your designers want
Sometimes, you need to tell the designers NO. Moving background images don't help people figure out what the weather is going to be.
18 hours ago
>Your designers want
Sometimes, you need to tell the designers NO. Moving background images don't help people figure out what the weather is going to be.
Assuming the app even works - since we're talking weather, allow me to offer an XKCD
https://xkcd.com/937/
Sometimes, you have to realize Hacker News is full of nerds that care about stuff nobody else cares about. Looks are so fucking important for many normal people. There's people that decide for or against a phone simply because it comes in a fun color.
They don't know why nerds care, but they will find out when they have to replace their PC just to have enough RAM to run a weather app.
But they won’t make the connection
Flashy beats functional nine times out of ten
Just look at the automotive industry
Many people enjoy a tasteful weather app. Granted a “minimal” UX toggle would be easy to add to reduce memory for those who cared.
I think the issue is with the recent definition creep of “tasteful.” Seems you might have the same mindset if you consider “minimal” to be the other option.
And sometimes your engineers need to be a LOT less stingy. 1GB is clearly overkill for an app such as this, but ~300MB is perfectly acceptable if it works well, looks good and does what it should do.
There is such a thing as overdesign, but when you’re building a modern application, you must trust your designer’s sense of aesthetics and knowledge of UX patterns—two things engineers are often notoriously bad at.
> ~300MB is perfectly acceptable if it works well, looks good and does what it should do.
No it isn't. It isn't a word process for gods sake. It has one literally one job and 300 MB is like an order of magnitude off for that. This mentalty is the slippery slope that led us to the situation in the OP today.
Dunno. Many designers are pretty bad at UX. They’re OK at aesthetics, but that’s not the same thing.
You're off by 2 orders of magnitude if you think that a not completely incompetently coded weather app genuinely needs that kind of resources - even allowing for aesthetic choices and modern UX patterns.
gp was talking about 87MB without animations how do you end up at your estimate?
Ah yes, Microsoft is famous for good modern UI/UX.
Honestly if the image is of the current weather it kinda does. I don't mind e.g Apple's weather app design at all
You probably have a SVG renderer in memory already, and you already have a frame buffer and/or compositor buffer(s). Why should adding a graphical representation of the weather require more than a few KiB?
In a composited window system (i.e., any Mac since Mac OS X and Windows since Vista [I think]), rendering from an SVG would have to occur in a window buffer owned by the application, so it wouldn't save any appreciable amount of memory, assuming the buffer is the size of the window. The days of having an application draw directly into the framebuffer are well in the past.
Because a big picture looks pretty sometimes?
Not sure what you think "having an SVG renderer in memory" means exactly, typically the way an SVG renderer works is that you give it a huge chunk of memory and ask it to draw pixel data there from the SVG file. So even though the SVG is small on disk, rendering a 1000x1000 image from an SVG is gonna need a 1000x1000x3 byte pixel buffer (assuming no transparency or HDR shenanigans)
2 replies →