Linked by Thom Holwerda on Sun 22nd Jul 2012 17:05 UTC
Graphics, User Interfaces Mike Elgan at Cult of Mac: "It must surely be a sign of the impending apocalypse that Microsoft's operating systems have 'more taste' than Apple's. I'm referring, of course, to Apple's inexplicable use of skeuomorphic design in iOS and OS X apps, and contrasting that with Microsoft's stark avoidance of such cheesy gimmickry in the Windows 8 and Windows Phone user interfaces. A skeuomorphic design in software is one that 'decorates' the interface with fake reality - say, analog knobs or torn paper. The problem is worse than it sounds." Won't come as a surprise to anyone that I wholeheartedly agree with this one. iOS and Mac OS X are ruined by an incredibly high Microsoft BOB factor. I have no idea how - or if - Apple will address this, or if the current downward spiral is going to continue.
Thread beginning with comment 527886
To view parent comment, click here.
To read all comments associated with this story, please click here.
henderson101
Member since:
2006-05-30

An ideal, for sure, but something I always thought we were working towards.


No. That idea died in the 2000's. I remember when it was a buzz word (circa 1998 - 2000) in the company I was working for. The IT Director decided we would gut all of our tools and make a fully component based approach. The analysis tool would sit on the computation engine. The document viewer would sit on the computation engine. It would all be COM-like (this was Windows NT4 era) but not COM. We started to create this product (it was more complicated than I list here, many more components, but I don't have time to go in to specifics..)

I left the company around April 2000. My last week I spent time with the team working on the component project. I'd been mainly maintaining the current builds, as this was the bread an butter of the company. Components were unproven. I asked for a demo... I wished I hadn't. The demo did everything the old tools did. But where the old tools batched the process (as they were specific tools), this monstrosity had a shell that loaded components on demand. So, rather than using batched of data processed over night, it processed the entire batch at time of "displaying" the final result. It took an hour. I asked about caching, but I was told the architecture was too loose to really make that work. Because nothing was specific and everything fitted together so loosely, it was pretty hard to get anything working efficiently without hardcoding functionality. That defeated the purpose.

So, I visited them again a few years later. You know what? They'd jettisoned that entire team, save 1 manager, run out of money, laid off all the other developers and had hired contractors to maintain the original source base that I'd worked on for 2 years. The "generic" product was gone.

After all that rambling anecdotal reminiscing, what conclusion can I put forward? Component based software is ridiculously hard to get working in the manor you describe. No one was working towards what you describe. Not really. You would need an architecture predefined that could handle anything you throw at it, and that is a fractal that just has no solution at the moment. Since my first encounter with componentized development, no company I have ever worked for in the last 10+ years has ever attempted anything as ambitious as that (and I've worked/contracted in a lot of different industries.) It's just too complicated for a single company to achieve without a lot of other external companies buying in to the idea.

Reply Parent Score: 3