People who think the purpose of the left lane is to drive the exact same speed as the car to your right so other drivers are tempted to perform dangerous maneuvers just to get around your inconsiderate punk ass, rather than submit to your roadblock
Spoken like someone who thinks the purpose of the left lane is to allow someone to exceed the legal speed limit. The left lane is for passing traffic not traveling the legal speed limit.
Someone traveling the legal speed limit is not an obstacle, they are a responsible, law-abiding citizen. What lane they are in is irrelevant, since there is no legal justification for exceeding the legal speed limit to pass them.
The root cause of the problem you cite is poor impulse control. There is no compelling reason for society to tolerate an inability to exercise self restraint and drive the legal speed limit. It does not matter if you agree that this is true because it is true; it is self-evident from even the most casual appraisal of the facts.
I'm beating a horse that's been dead for almost ten years, and it's been called, rather amusingly, "Compatibility with the Monopoly". To quote an article written in 2000: "...95 percent of the world uses a two-button mouse."
Apple has had support for a two-button mouse for almost ten years. And that decision was made at the time to conform to the de facto standard. I'm not inventing any of this because I don't have to.
is a flaw. I want Apple HID guidelines to support a standard, and I want that standard to make sense and not restrict the way I use my computer because Jobs doesn't like buttons. I want my computer to be usable.
Apple occasionally makes poor decisions, then defends them with near-religious zeal, as do its legions of followers. I don't care about any of that. Apple's personality (?) as a company interferes with its ability to critically evaluate its own decisions. This has had a far greater impact on the company than the problems with the Apple III, Macintosh, or Lisa reported.
Anyway, the decision to put the minimize/zoom buttons in the upper, left-hand corner of the window is a decision that goes against my "technocratic" bias. I'd prefer to be able to decide where they appear, as I can in KDE. But I don't consider it a flaw, because it's not. It's a personal preference.
Like the "resize the window to fit the content" problem that Preview has.
Or the "one-button mouse" problem. I'm not willing to debate the meaning of the word "consistent" in this context, because I have a feeling it would be useless, but the company that doesn't conform to the de facto standard is the one which lacks consistency, and in this case it was Apple. Apple embraced the two-button mouse, so that problem has since been corrected, but that doesn't change the fact that many other idiosyncrasies of Apple computers deserve to meet the same fate, and the sooner the better.
is that Apple will follow their own HID guidelines. You are correct that "appropriate" behavior isn't mandated by Apple. That would be intolerable. But window behavior isn't standard even across Apple's own applications.
as I said, the one-button mouse is only really interesting because it's symptomatic of Apple's design philosophy. And that philosophy results in problems Apple won't correct, which is a much larger problem than any single "classic computer" ever had, including the Macintosh or Lisa, because it's one thing all Apple computers have shared.
The "classical age of computing" and X11 have nothing to do with that.
Personally, I think that level of customization is beyond what most users require, and I don't have a problem with application developers controlling what the context menu is used for in their applications.
I know that I find clicking and holding the mouse button (or trackpad button, or trackpad) to be mentally equivalent to a comma, in the middle of a sentence. It's an unnecessary pause.
In general, I don't reply to Anonymous Cowards, but your objection is fair.
Simply put: I work in front of computers all day, and I want the text larger to reduce eyestrain.
I want the window to resize to fit the content. In your example, the content is a line of text. In my example, it is the page of a document (PDF). If the right text size for me results in content larger than the current window, and I click the zoom button, I want the window to resize to fit the content. If that would result in a window larger than the screen itself, I want the window to occupy the whole screen. This behavior is not standard in OSX. That's a problem for me.
The first is a failure in Preview. Preview doesn't resize the window to fit the contents in accordance with Apple's HID standards, and Preview is copyright Apple Inc., not some third party.
The second is a failure in ical. Clicking "one hour before event" should reset the reminder to one hour before the event, not one hour before the mouse click.
The third was the result of a decision by Apple to "fix" OSX so that afp over ssh connections would not fail silently, because OSX clients don't support afp connections over ssh. Why doesn't the "fix" default to a secure connection OSX supports, and not afp, when the button is clicked?
Really. You can tell me an OS can't be all things to all people, and I completely agree, but these are problems that need to be corrected, not "features".
I've been at this a long time. And I had to explain how to set the clock on a VCR to my parents when I was a kid, and tune a UHF dial. But none of those things are important.
We're talking about Apple's failure to implement relatively simple UI features that its users want. And my point is that Apple's stubborn insistence that people use its computers the way Apple intended for them to be used affects their user acceptance.
I think your example supports my conclusion better than it supports yours. More people use a two-button mouse than use a one-button mouse, so I don't buy the "there's an intellectual barrier to entry" argument.
The maximize window button is just another feature people want that Apple won't implement. Some of us spend all day in front of our computers and we want to be able to read without eyestrain. The zoom button doesn't reliably size the window to fit the contents, even if the window will fit on the screen. That's a problem.
That was one of the most serious design mistakes of the last thirty years, but it's only really interesting because it's symptomatic of Apple's design philosophy, which is: "Do as I wilt".
The one-button mouse spanned multiple generations of Apple computers and underscored Apple's stubborn unwillingness to produce computers that do what their users want, and not what Jobs or Apple's HID team think they should do.
Really. Apple refuses to correct the annoyances of the UI that should not exist. Why doesn't OSX have a maximize window button? Why does clicking on "one hour before event" for an ical event reset the clock to one hour before the time you click the button, and not one hour before the event? Why doesn't finder support afp connections over ssh?
None of those things seem to be complex, every one of them is a failure of the UI, and yet none of them have been corrected.
Yes, and the logical result of promising more than you can effectively deliver over the long term is that your experienced people depart for your competitors, taking their knowledge and experience with them.
Also, I've seen organizations enter negotiations with their customers because they were unable to manage this, and either demand a cost increase to offer "incentive pay" to their employees to induce them to stay, or a cost increase with impact to schedule to train the remaining employees to the knowledge and experience level of their departed employees.
In the end, it always comes down to the organization's ability to track where their dollars are being spent, and for what. If an organization is able to do that, they can determine if its improvement initiatives are really having the desired impact, or if they've cut too deep or too fast. When it's not able to do that all conclusions are based on projected cost savings, which are useless because they can be made to confirm or affirm any opinion management may have.
And if an organization is able to determine if its improvement initiatives are having the desired impact, offering bonuses for actual savings is an excellent incentive.
In part, yes. Deming's "Plan-Do-Check-Act" cycle is still an essential teaching tool. However, as with most business management philosophies, he re-packages or re-states effective business management practices that were well known in his day and which have since been repackaged many times.
My theory is that every six or so years, the management world needs a refresher in effective business management practices, but that management is unwilling to part with good money for something they've already "learned". That's why the names of the strategies change every so many years: Total Quality Management (TQM), LEAN, Six Sigma... They're "management fads". They make whoever packages them a lot of money, whoever gets in on the ground floor a little less, spread a lot of money around to consultants, trainers, etc., and are ultimately good for business, like a good bloodletting.
People with an almost fanatical devotion to their particular ideology don't recognize the similarities, but those similarities exist.
For example: what's "muda"? It's waste, but it's not just paper waste, or scrap metal, it's wasted time, during which an employee of the organization is not productive, or time management is wasting on non value-added activities like moving paper from one pile on a desk to another.
That's no different now than it was in Deming's day.
ITIL is unimplementable, as written. That's why an entire industry exists to interpret and apply it.
ITIL lacks a quality framework, including a corrective and preventive action procedure.
To ITIL's credit, it does not claim to provide either of these things. Its focus is, as you observe, IT service management. However, without a clear implementation or quality framework, ITIL is incomplete.
I've seen shops that claim to have aligned themselves with ITIL, but they've all been miserable failures, top-heavy, and with no clear understanding of what, exactly, a service is, why it should be improved, and for what reasons.
I worked for a company that was unable to meet its operating margin for eight years. Senior management's solution was to replace the management team responsible for failing to meet their targets by transferring them horizontally across the company until they had learned their lesson: there's no consequence for repeated failure to meet your goals.
Every horizontal transfer of management was accompanied by another round of employee layoffs, forced by the new management, in a vain effort to book a profitable quarter. The result was that most employees were absolutely terrified they would lose their jobs in the next re-organization and were utterly unwilling to participate in process documentation efforts because they were valuable as long as no one else knew how to do their jobs.
That company is one of the top three defense contractors in the United States. The money senior management was wasting? It was provided by the United States taxpayer.
No, because there aren't any. As I said, bad process engineers are a dime a dozen, and they've been prolific. The signal-to-noise ratio is very low. Most call it "business process re-engineering", but that's a misnomer if your process engineering was haphazard to begin with.
If you're really interested in process engineering, you should start with ISO 9001 (or MIL-Q-9858 or a comparable quality standard), take some basic root cause analysis training, and lead a corrective and preventive action initiative. You never really know where the problems are until you trace the process to its sources of failure, despite what the dominant personality in the room has to say. Once you've done that a few times, you'll realize that it's better to engineer the process to eliminate the common and preventable sources of failure than to allow them to recur, and then correct them, because corrective action is expensive.
In the old days, some of process engineering was called "efficiency engineering", "industrial engineering", or, at Virginia Tech, "Industrial Engineering and Operations Research". Those disciplines are better utilized by a single organization which makes a large number of a very limited inventory, and by which a few seconds shaved from the production time of each unit represent a substantial savings or increase in production, depending on your focus, over some finite period of time.
Business process engineering isn't about that. It's about reducing costs and increasing efficiency, and providing the organization with the ability to take on additional growth work, or have the excess capacity to meet increased demand from existing customers.
No. The problem you are describing is "the blind men and the elephant". That's not the problem I was describing.
What you're talking about any competent technical writer or process engineer should be able to overcome by determining what the organization's minimum technical competency is for the given task, and what specific work experience is appropriate for that task. That information should have been in the job description for the work which the individuals were hired to accomplish for the organization, or in a training program designed to give the employee sufficient domain knowledge to mature into the organization.
The problem I was describing is caused by the weak link in the chain: management, and for a variety of reasons I don't want to delve into too deeply. Briefly, because management is always looking for a way to reduce cost, the prevailing strategy has been to reduce headcount as a way to reduce cost. And this is most readily achieved by reducing all employees to the skill level of the least competent employee.
You need a competent process engineer, and good ones are expensive. Bad ones are a dime a dozen, and will drive your costs up by insisting, for example, that every procedure be a documented procedure, that every process needs to be flowcharted, that there's a distinction between a process and the document describing the process, or that the fiction that is RACI is not reducible to a single directive: "accountable".
This is, as they say, job security for the process engineers because they're constantly chasing a moving target. Also, the instant employees realize or suspect that they're being made interchangeable by participating in any process engineering effort, they'll learn to conceal key details which will make all work to date useless.
Organizations that don't realize that have chosen the way of pain. Yours is probably one of them.
Wikipedia's content is generated by pseudo-anonymous individuals who incorrectly assert the public Internet is a reliable source of information. The public Internet is not a reliable source of information, therefore wikipedia is not a reliable source.
Wikipedia is not an objective source.
Wikipedia's editors break the rules governing their behavior and the behavior of others if it will benefit them. As a result, wikipedia advances the subjective views and beliefs of its editors.
Wikipedia is not a representative source.
Contributing factors to this delusion include the competing concepts "notability" and "neutrality", as advanced by wikipedia. Lacking from that discussion, of course, is the question: notable or neutral, to who? Rather than host disputed versions of articles, representing the majority opinion and any significant minority opinions, wikipedia prefers a version advancing assertions, but not facts, which are easily disputed by any minority.
And I frankly despise the appearance of wikipedia in search results, or having some article on wikipedia quoted in a discussion online, as if it provides information of value, in lieu of the reliable primary sources wikipedia references, as if wikipedia itself is the source of that information, and not merely a link farm with some content wrapped around it.
But then, I make a living because of the difference between assertions and facts, and I'm apt to notice such things. Wikipedia is long on assertions, and short on facts.
This is the status quo. How many times have you called the help desk to report a problem, only to have them tell you to reboot? When you call the company that made your computer, and you're in the queue waiting to speak to someone, in their litany of instructions you will hear the following: "Please reboot your computer".
When did the "Microsoft Solution" become commonplace? When Microsoft managed to convince the people who use their software that the expectation that their information technology infrastructure will be reliable is unreasonable.
Several factors contribute to this problem: disclaimer of fitness for an intended purpose, lack of liability, a software ecosystem that has relied for far too long on "experts" who haven't read the book that came with their certification, and a lack of any real measure of lost productivity due to poor information technology decisions, in general. And Microsoft has been able to use its dominant position to stave off market forces. The market isn't making Microsoft's software better, and neither is Microsoft.
But good luck getting management or anyone else making a purchasing decision to embrace the idea that a software company should be at least as responsible as any company that manufactures a real, physical product for the quality of their product.
for Apple to release a true "book-styled" macbook, which opens sideways like a book for reading, has a multitouch widescreen LCD display, and a full laptop keyboard with large trackpad (like the current generation macbooks).
So, I don't want extra vertical space in my mobile computer monitor, unless it's being used as a reader, in which case it will be on its side. That's what a docking station with an external monitor is for.
coding is better left to those who understand the difference between "to" and "too", or "can not" and "cannot".
Basic errors like that undermine the credibility of the "superannuated".
Spoken like someone who thinks the purpose of the left lane is to allow someone to exceed the legal speed limit. The left lane is for passing traffic not traveling the legal speed limit.
Someone traveling the legal speed limit is not an obstacle, they are a responsible, law-abiding citizen. What lane they are in is irrelevant, since there is no legal justification for exceeding the legal speed limit to pass them.
The root cause of the problem you cite is poor impulse control. There is no compelling reason for society to tolerate an inability to exercise self restraint and drive the legal speed limit. It does not matter if you agree that this is true because it is true; it is self-evident from even the most casual appraisal of the facts.
"Nixon's had an asshole transplant... Apparently, the asshole's rejected him!"
I'm beating a horse that's been dead for almost ten years, and it's been called, rather amusingly, "Compatibility with the Monopoly". To quote an article written in 2000: "...95 percent of the world uses a two-button mouse."
Apple has had support for a two-button mouse for almost ten years. And that decision was made at the time to conform to the de facto standard. I'm not inventing any of this because I don't have to.
is a flaw. I want Apple HID guidelines to support a standard, and I want that standard to make sense and not restrict the way I use my computer because Jobs doesn't like buttons. I want my computer to be usable.
Apple occasionally makes poor decisions, then defends them with near-religious zeal, as do its legions of followers. I don't care about any of that. Apple's personality (?) as a company interferes with its ability to critically evaluate its own decisions. This has had a far greater impact on the company than the problems with the Apple III, Macintosh, or Lisa reported.
Anyway, the decision to put the minimize/zoom buttons in the upper, left-hand corner of the window is a decision that goes against my "technocratic" bias. I'd prefer to be able to decide where they appear, as I can in KDE. But I don't consider it a flaw, because it's not. It's a personal preference.
Like the "resize the window to fit the content" problem that Preview has.
Or the "one-button mouse" problem. I'm not willing to debate the meaning of the word "consistent" in this context, because I have a feeling it would be useless, but the company that doesn't conform to the de facto standard is the one which lacks consistency, and in this case it was Apple. Apple embraced the two-button mouse, so that problem has since been corrected, but that doesn't change the fact that many other idiosyncrasies of Apple computers deserve to meet the same fate, and the sooner the better.
is that Apple will follow their own HID guidelines. You are correct that "appropriate" behavior isn't mandated by Apple. That would be intolerable. But window behavior isn't standard even across Apple's own applications.
as I said, the one-button mouse is only really interesting because it's symptomatic of Apple's design philosophy. And that philosophy results in problems Apple won't correct, which is a much larger problem than any single "classic computer" ever had, including the Macintosh or Lisa, because it's one thing all Apple computers have shared.
The "classical age of computing" and X11 have nothing to do with that.
Personally, I think that level of customization is beyond what most users require, and I don't have a problem with application developers controlling what the context menu is used for in their applications.
I know that I find clicking and holding the mouse button (or trackpad button, or trackpad) to be mentally equivalent to a comma, in the middle of a sentence. It's an unnecessary pause.
Yes, that was intentional.
In general, I don't reply to Anonymous Cowards, but your objection is fair.
Simply put: I work in front of computers all day, and I want the text larger to reduce eyestrain.
I want the window to resize to fit the content. In your example, the content is a line of text. In my example, it is the page of a document (PDF). If the right text size for me results in content larger than the current window, and I click the zoom button, I want the window to resize to fit the content. If that would result in a window larger than the screen itself, I want the window to occupy the whole screen. This behavior is not standard in OSX. That's a problem for me.
if Apple's UI was consistent.
Of the three examples I gave:
Really. You can tell me an OS can't be all things to all people, and I completely agree, but these are problems that need to be corrected, not "features".
I've been at this a long time. And I had to explain how to set the clock on a VCR to my parents when I was a kid, and tune a UHF dial. But none of those things are important.
We're talking about Apple's failure to implement relatively simple UI features that its users want. And my point is that Apple's stubborn insistence that people use its computers the way Apple intended for them to be used affects their user acceptance.
I think your example supports my conclusion better than it supports yours. More people use a two-button mouse than use a one-button mouse, so I don't buy the "there's an intellectual barrier to entry" argument.
The maximize window button is just another feature people want that Apple won't implement. Some of us spend all day in front of our computers and we want to be able to read without eyestrain. The zoom button doesn't reliably size the window to fit the contents, even if the window will fit on the screen. That's a problem.
isn't the question. Apple's failure to include a relatively simple UI feature that many of its users want is the problem.
As I said, it's symptomatic of their approach to UI in general, which is: "we'll decide what you want to do", or "Do as I wilt".
That was one of the most serious design mistakes of the last thirty years, but it's only really interesting because it's symptomatic of Apple's design philosophy, which is: "Do as I wilt".
The one-button mouse spanned multiple generations of Apple computers and underscored Apple's stubborn unwillingness to produce computers that do what their users want, and not what Jobs or Apple's HID team think they should do.
Really. Apple refuses to correct the annoyances of the UI that should not exist. Why doesn't OSX have a maximize window button? Why does clicking on "one hour before event" for an ical event reset the clock to one hour before the time you click the button, and not one hour before the event? Why doesn't finder support afp connections over ssh?
None of those things seem to be complex, every one of them is a failure of the UI, and yet none of them have been corrected.
Yes, and the logical result of promising more than you can effectively deliver over the long term is that your experienced people depart for your competitors, taking their knowledge and experience with them.
Also, I've seen organizations enter negotiations with their customers because they were unable to manage this, and either demand a cost increase to offer "incentive pay" to their employees to induce them to stay, or a cost increase with impact to schedule to train the remaining employees to the knowledge and experience level of their departed employees.
In the end, it always comes down to the organization's ability to track where their dollars are being spent, and for what. If an organization is able to do that, they can determine if its improvement initiatives are really having the desired impact, or if they've cut too deep or too fast. When it's not able to do that all conclusions are based on projected cost savings, which are useless because they can be made to confirm or affirm any opinion management may have.
And if an organization is able to determine if its improvement initiatives are having the desired impact, offering bonuses for actual savings is an excellent incentive.
In part, yes. Deming's "Plan-Do-Check-Act" cycle is still an essential teaching tool. However, as with most business management philosophies, he re-packages or re-states effective business management practices that were well known in his day and which have since been repackaged many times.
My theory is that every six or so years, the management world needs a refresher in effective business management practices, but that management is unwilling to part with good money for something they've already "learned". That's why the names of the strategies change every so many years: Total Quality Management (TQM), LEAN, Six Sigma... They're "management fads". They make whoever packages them a lot of money, whoever gets in on the ground floor a little less, spread a lot of money around to consultants, trainers, etc., and are ultimately good for business, like a good bloodletting.
People with an almost fanatical devotion to their particular ideology don't recognize the similarities, but those similarities exist.
For example: what's "muda"? It's waste, but it's not just paper waste, or scrap metal, it's wasted time, during which an employee of the organization is not productive, or time management is wasting on non value-added activities like moving paper from one pile on a desk to another.
That's no different now than it was in Deming's day.
ITIL is unimplementable, as written. That's why an entire industry exists to interpret and apply it.
ITIL lacks a quality framework, including a corrective and preventive action procedure.
To ITIL's credit, it does not claim to provide either of these things. Its focus is, as you observe, IT service management. However, without a clear implementation or quality framework, ITIL is incomplete.
I've seen shops that claim to have aligned themselves with ITIL, but they've all been miserable failures, top-heavy, and with no clear understanding of what, exactly, a service is, why it should be improved, and for what reasons.
I think we're basically saying the same thing.
I worked for a company that was unable to meet its operating margin for eight years. Senior management's solution was to replace the management team responsible for failing to meet their targets by transferring them horizontally across the company until they had learned their lesson: there's no consequence for repeated failure to meet your goals.
Every horizontal transfer of management was accompanied by another round of employee layoffs, forced by the new management, in a vain effort to book a profitable quarter. The result was that most employees were absolutely terrified they would lose their jobs in the next re-organization and were utterly unwilling to participate in process documentation efforts because they were valuable as long as no one else knew how to do their jobs.
That company is one of the top three defense contractors in the United States. The money senior management was wasting? It was provided by the United States taxpayer.
So, yes. Bad decisions abound.
No, because there aren't any. As I said, bad process engineers are a dime a dozen, and they've been prolific. The signal-to-noise ratio is very low. Most call it "business process re-engineering", but that's a misnomer if your process engineering was haphazard to begin with.
If you're really interested in process engineering, you should start with ISO 9001 (or MIL-Q-9858 or a comparable quality standard), take some basic root cause analysis training, and lead a corrective and preventive action initiative. You never really know where the problems are until you trace the process to its sources of failure, despite what the dominant personality in the room has to say. Once you've done that a few times, you'll realize that it's better to engineer the process to eliminate the common and preventable sources of failure than to allow them to recur, and then correct them, because corrective action is expensive.
In the old days, some of process engineering was called "efficiency engineering", "industrial engineering", or, at Virginia Tech, "Industrial Engineering and Operations Research". Those disciplines are better utilized by a single organization which makes a large number of a very limited inventory, and by which a few seconds shaved from the production time of each unit represent a substantial savings or increase in production, depending on your focus, over some finite period of time.
Business process engineering isn't about that. It's about reducing costs and increasing efficiency, and providing the organization with the ability to take on additional growth work, or have the excess capacity to meet increased demand from existing customers.
No. The problem you are describing is "the blind men and the elephant". That's not the problem I was describing.
What you're talking about any competent technical writer or process engineer should be able to overcome by determining what the organization's minimum technical competency is for the given task, and what specific work experience is appropriate for that task. That information should have been in the job description for the work which the individuals were hired to accomplish for the organization, or in a training program designed to give the employee sufficient domain knowledge to mature into the organization.
The problem I was describing is caused by the weak link in the chain: management, and for a variety of reasons I don't want to delve into too deeply. Briefly, because management is always looking for a way to reduce cost, the prevailing strategy has been to reduce headcount as a way to reduce cost. And this is most readily achieved by reducing all employees to the skill level of the least competent employee.
but I can be bought.
You need a competent process engineer, and good ones are expensive. Bad ones are a dime a dozen, and will drive your costs up by insisting, for example, that every procedure be a documented procedure, that every process needs to be flowcharted, that there's a distinction between a process and the document describing the process, or that the fiction that is RACI is not reducible to a single directive: "accountable".
This is, as they say, job security for the process engineers because they're constantly chasing a moving target. Also, the instant employees realize or suspect that they're being made interchangeable by participating in any process engineering effort, they'll learn to conceal key details which will make all work to date useless.
Organizations that don't realize that have chosen the way of pain. Yours is probably one of them.
Wikipedia is not authoritative.
Wikipedia's content is generated by pseudo-anonymous individuals who incorrectly assert the public Internet is a reliable source of information. The public Internet is not a reliable source of information, therefore wikipedia is not a reliable source.
Wikipedia's editors break the rules governing their behavior and the behavior of others if it will benefit them. As a result, wikipedia advances the subjective views and beliefs of its editors.
Contributing factors to this delusion include the competing concepts "notability" and "neutrality", as advanced by wikipedia. Lacking from that discussion, of course, is the question: notable or neutral, to who? Rather than host disputed versions of articles, representing the majority opinion and any significant minority opinions, wikipedia prefers a version advancing assertions, but not facts, which are easily disputed by any minority.
And I frankly despise the appearance of wikipedia in search results, or having some article on wikipedia quoted in a discussion online, as if it provides information of value, in lieu of the reliable primary sources wikipedia references, as if wikipedia itself is the source of that information, and not merely a link farm with some content wrapped around it.
But then, I make a living because of the difference between assertions and facts, and I'm apt to notice such things. Wikipedia is long on assertions, and short on facts.
Glass is not a liquid of any kind, "technically" or otherwise.
Glass is a solid.
Glass is not a crystalline solid.
Glass is an amorphous solid.
Yes, I am a materials engineer.
This is the status quo. How many times have you called the help desk to report a problem, only to have them tell you to reboot? When you call the company that made your computer, and you're in the queue waiting to speak to someone, in their litany of instructions you will hear the following: "Please reboot your computer".
When did the "Microsoft Solution" become commonplace? When Microsoft managed to convince the people who use their software that the expectation that their information technology infrastructure will be reliable is unreasonable.
Several factors contribute to this problem: disclaimer of fitness for an intended purpose, lack of liability, a software ecosystem that has relied for far too long on "experts" who haven't read the book that came with their certification, and a lack of any real measure of lost productivity due to poor information technology decisions, in general. And Microsoft has been able to use its dominant position to stave off market forces. The market isn't making Microsoft's software better, and neither is Microsoft.
But good luck getting management or anyone else making a purchasing decision to embrace the idea that a software company should be at least as responsible as any company that manufactures a real, physical product for the quality of their product.
for Apple to release a true "book-styled" macbook, which opens sideways like a book for reading, has a multitouch widescreen LCD display, and a full laptop keyboard with large trackpad (like the current generation macbooks).
So, I don't want extra vertical space in my mobile computer monitor, unless it's being used as a reader, in which case it will be on its side. That's what a docking station with an external monitor is for.