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 527848
To view parent comment, click here.
To read all comments associated with this story, please click here.
siraf72
Member since:
2006-02-22

Do you mean Document-centric in an OpenDoc type approach?

For me, I find documents becoming less and less relevant as the Data they contain (including presentation of the data) tends to exist in various places. I might have a .doc a pdf and a copy on google docs of the same document. Only the actual data within it matters. Increasingly, applications pass data to each other via APIs and keep local (often hidden documents).

What difference does it make if where the focus lies? If applications are too cumbersome they will be replaced by less cumbersome ones.

For me, I think looking for a one size fits all document-centric approach sounds nice but also like an impossible ideal.

Reply Parent Score: 2

Thom_Holwerda Member since:
2005-06-29

What difference does it make if where the focus lies?


A huge one. Now, if I want to edit a bit of text in a word document, I have to load up ALL of Word - even if the doc only has text in it, it still loads up everything else, unrelated to text editing.

In a proper document-centric approach, you'd load up the doc, and when you start editing text, it automatically loads the appropriate text editing engine (preferably all standardised), and ONLY that. If you double click on a picture in the doc, the picture editing component is loaded.

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

Reply Parent Score: 1

siraf72 Member since:
2006-02-22

Actually you can open Word or Text Edit, or Google docs, or Pages, etc, etc.

Provided the applications plays nice with the data, you have options to load the one you find least obtrusive.

I think the ideal you are reffering has too many design problems. You would need a standardized document component model which would add complexity rather than remove it. I think Apple's OpenDoc experiment provides a useful reference.

Rather than trying to plan and design something like that, let the Applications fight it out. Those that play nice and are least obtrusive will win. - OK, that's also in an ideal world, but it requires a less ideal one than yours. Especially as yours has unicorns!

Reply Parent Score: 2

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