Hacker News Reader

Comment by talmand | Hacker News Reader

Don't like that feature of Windows Update? Turn off automatic updates and do it manually when you wish.

Although I agree with the annoyance of accidentally opening something like Photoshop and having to wait to close it. But a good number of resources that is loading is third-party stuff that demands to be present immediately on startup as opposed to being loaded on demand. But whatever.

Paint has the same UI as what? I hope you're not comparing it to Photoshop or any other professional level software. I believe the modern version of Word is a good bit more than a glorified textbox.

But then you point out exactly why these programs load slowly in your last sentence. Maybe just start using less complex software?

View on HN

Their interface is the same. Are you utterly blind? Stop looking at the UX as a programmer and imagining the complexity of the features. The actual screen is displaying exactly the same stuff. There's a big white box to draw in and bunch of buttons to press.

You do not need to initalize all the 3rd party tools, you just have to find out which tiny little icon to add on a task bar or extra menu items to add, and why didn't you cache that when the extension was first detected?

And how silly of me, of course all the corporations these days let you turn off the updates on their computers don't they?

Stop telling your users that 'if they just..', do the opposite with UI than you do with your code, start programming for the best case scenario, not the worst case.

I once wrote a clone of Microsoft Word for a company looking to move away from Office dependency - I think you're really understating the complexity of something like Word when you call it a glorified textbox or say it should load as quickly as MSPaint because they both use the ribbon UI.

>I once wrote a clone of Microsoft Word for a company

Out of curiosity, when was it? Wasn't openoffice.org an option?

The chief complaint I have with HN's lack of reply notifications is that interesting questions like this one will go unanswered forever.

The interface may be the same but I'm willing to bet under the hood they are quite different on a large scale. You seem unwilling to admit that.

I don't understand what you are saying about third party tools. Could you clarify? Is that whole sentence talking about the same thing because I read it as having four different topics in there.

If a corporation won't allow you to adjust update settings then that's an issue to take up with IT since they are preventing you from doing what you need, not the software itself. What if the default settings were exactly what you wanted and your IT department prevented it, is that also the fault of the software? I think your complaint is misdirected in this case.

Ask ten different people to define best case scenario and I bet you'll get several different answers. Which one do you choose? You can't make everyone happy but I guess since you're not happy then your way is the best choice? What you complain about telling users "if they just..." is what I call choice. When I say an application won't do something I need then I WANT the answer to be "if you just do this..." so I can have that choice.

>Their interface is the same. Are you utterly blind? Stop looking at the UX as a programmer and imagining the complexity of the features. The actual screen is displaying exactly the same stuff.

Seriously? I mean, my Dodge Neon has the same gas, brake, clutch and steering wheel that a Ferrari 599 has, why doesn't it 0-60 as fast? Stop comparing engine size and complexity, it has all the superficial elements of a sports car! God, you're such a mechanic.

I think I understand what he's saying. Sure, your Dodge Neon may take longer to go 0-60 (i.e. it's okay if Photoshop is slower overall), but there would be something wrong with it if it takes significantly longer just to get in the car (i.e. Photoshop shouldn't take longer to boot up).

No, I think the engine metaphor is pretty apt. I completely understand what he's saying, but the alternative he seems to imply is no better. Why would I want the interface to load but not be able to use it for another 45 seconds? Okay, so I'm in my car (clicked on the shortcut) but I won't be able to go anywhere (use the application) for a few minutes because it's slow to accelerate (load). Who cares about the max speed of your car as long as it 0-60s in a reasonable amount time?

Either way it's going to take some time to load because it's a big application. One way lets you know it's working, the other makes you think it has frozen as you're fruitlessly clicking around. The interface is the least important thing in the application until it's fully loaded.

I think it makes sense. To extend your metaphor, you can do things such as turn on the radio without noticing a performance difference between the two cars.

The idea with Photoshop is, sure, loading the entire thing will take much longer, but users tend to use one tool at a time, and loading an individual tool shouldn't take anywhere near as long.

It also makes sense from the point of view of parallelization. One example of an extremely slow operation is waiting for the user to click on something. So instead of sequentially loading things, followed by the user deciding what to do, Photoshop should continue loading while the user decides e.g. what brush size and color he/she wants.

Like any other, this approach has advantages and disadvantages - it would indeed be frustrating if the brush tool hadn't loaded by the time you started using it, and it would probably require a lot of work for Photoshop to load so modularly and on-demand - but all I'm saying is, I understand the value in the alternative he suggests.

To go beyond cars and Photoshop, the RPG Guild Wars is a good example of only loading what you need. In fact, it doesn't even download the other game zones before you need them. If it sees you running towards the next zone, it begins a buffer in the background to pull in the data. So instead of making you wait while the game downloads and installs everything right up front, it downloads then loads up exactly what you need. This is much harder in an application, which is more non-linear.

When you run a program the OS will usually just map the code into address space, it won't necessarily actually load the code from the disk until it needs to.

It's possible that what the program is doing at initialization is not loading code from the disk but doing something else, like perhaps checking it has a nice big contiguous area of disk to use for temporary storage or for loading some type of cache into.

There are many times in programming where you make a choice between taking a one-off up front cost to optimise something for faster overall performance vs slower overall performance without the setup cost.

For example with a DBMS you can lose some write performance by having an index on a table and rebalancing when you are writing but the advantage is much faster read performance.

Also A Java program can take longer to run the first time by JIT compiling the program for the platform it is run on but this will mean faster performance of the program itself.

Reply on news.ycombinator.com