Is Anyone in Charge?
Does anyone in the Mac OS and APP Software Development organization know what Requirements Management or Configuration Management/Change Control is?
Having been a Software Development engineer and manager for over 30 years and a Mac/Lisa Evangelist since 1982, I have been very disturbed by the GUI changes that Apple has made to the OS X over the past 10 years especially to the iPhone & iTunes apps and to its basic OS. Users have invested millions of man hours into using these apps to manage their databases of photos, videos and music. Apple’s changes to these apps without regard to user impact is unprofessional, immature and outrageous.
The fact that Apple allows these kind of app GUI and functional changes without regard to their impact on its user community SHOULD make every user think twice about using Apple’s iCloud service. When a user allows a 3rd party to gain control of their data and information, that user becomes a potential hostage to the 3rd party in the future and may have to pay to get their data and information back and it may not even be available in the future. The PC “Revolution” was about users getting control of their hardware, software and more importantly, their data, and away from the totalitarian control of main frame IT departments. Now the megalithic computer companies have found a way to get control of user data again. This can potentially expose a user’s data and information to “unrestricted” access by anyone who can “hack” their systems or from government agencies data mining and snooping for information.
Any change to an established GUI should be a very critical concern of any Software Manager who has any concept of user impacts. GUI changes should only be done to fix a major error or to add new features, which should not impact the GUI for current features unless ABSOLUTELY necessary.
The most costly investment a user makes in any software is in the user training to become productive in its use.
This is where the GUI makes or breaks the user experience and is a major factor in his decision to continue its use or toss it and replace it with another app with a more familiar and user friendly GUI.
When Apple makes changes to the GUI with no apparent benefit except that some naive, inexperienced programmers decided they didn't like the old way and wanted to "make it their own", it costs the user community literally hundreds of thousands of man hours in lost time adjusting to the new GUI without any added benefit. And it creates frustration and disappointment with the app. It also creates a sense of betrayal and fear that other unneeded changes to the GUI will follow with more lost time.
There should be a strictly controlled change control process when any contemplated GUI change is being considered.
A change request must be created and thoroughly reviewed especially with the impact on users being the foremost consideration. Current features/capabilities should NOT be eliminated without extensive evaluation and feedback from the user community. Is there a Mac OSX User Group that is involved in OS X change control?
When new features are added, the GUI should be consistent with the current feature GUI as much as possible. Obviously, when a released feature's GUI proves to be cumbersome and unproductive, it should be revised. But revised only to minimum extent required. When a new GUI for current features can be justified based on consistency, improved productively and/or accuracy, then an option should be provided to current users to revert to the old GUI if they choose to for at least 1 or 2 releases/updates.
GUI changes should be beta tested by a broad base of REAL experienced users before being released. REAL user testers should be heavily weighted to LONG time users and not just based on younger, inexperienced users with very little investment in time relative to the current GUI.
In GUI software, change for change's sake should be quickly stopped and denied approval for implementation. Yosemite is a classic example of how not to upgrade software. It obviously was not very well tested before release. If there is one, the SW QA dept should be replaced.
The SW Engineering Manager should be fired for approving a Software Specification and GUI Specification that was Yosemite.
Did anyone on the SW Engineering Development team have ANY extensive experience using Mac OS X?
Maverick was a significant change from Mountain Lion but it was still recognizable as a Mac OS.
Yosemite looked like a rejected Windoze OS release.
Being a long time Apple shareholder and a Mac Evangelist since 1984 (even had a Lisa in 1982!), I am deeply concerned that Apple is loosing it's way.
A user friendly, well tested GUI was Apple's discriminator and is what created a loyal user base. Let's hope Apple does not lose sight of their product’s best feature.
Does anyone in the Mac OS and APP Software Development organization know what Requirements Management or Configuration Management/Change Control is?
Having been a Software Development engineer and manager for over 30 years and a Mac/Lisa Evangelist since 1982, I have been very disturbed by the GUI changes that Apple has made to the OS X over the past 10 years especially to the iPhone & iTunes apps and to its basic OS. Users have invested millions of man hours into using these apps to manage their databases of photos, videos and music. Apple’s changes to these apps without regard to user impact is unprofessional, immature and outrageous.
The fact that Apple allows these kind of app GUI and functional changes without regard to their impact on its user community SHOULD make every user think twice about using Apple’s iCloud service. When a user allows a 3rd party to gain control of their data and information, that user becomes a potential hostage to the 3rd party in the future and may have to pay to get their data and information back and it may not even be available in the future. The PC “Revolution” was about users getting control of their hardware, software and more importantly, their data, and away from the totalitarian control of main frame IT departments. Now the megalithic computer companies have found a way to get control of user data again. This can potentially expose a user’s data and information to “unrestricted” access by anyone who can “hack” their systems or from government agencies data mining and snooping for information.
Any change to an established GUI should be a very critical concern of any Software Manager who has any concept of user impacts. GUI changes should only be done to fix a major error or to add new features, which should not impact the GUI for current features unless ABSOLUTELY necessary.
The most costly investment a user makes in any software is in the user training to become productive in its use.
This is where the GUI makes or breaks the user experience and is a major factor in his decision to continue its use or toss it and replace it with another app with a more familiar and user friendly GUI.
When Apple makes changes to the GUI with no apparent benefit except that some naive, inexperienced programmers decided they didn't like the old way and wanted to "make it their own", it costs the user community literally hundreds of thousands of man hours in lost time adjusting to the new GUI without any added benefit. And it creates frustration and disappointment with the app. It also creates a sense of betrayal and fear that other unneeded changes to the GUI will follow with more lost time.
There should be a strictly controlled change control process when any contemplated GUI change is being considered.
A change request must be created and thoroughly reviewed especially with the impact on users being the foremost consideration. Current features/capabilities should NOT be eliminated without extensive evaluation and feedback from the user community. Is there a Mac OSX User Group that is involved in OS X change control?
When new features are added, the GUI should be consistent with the current feature GUI as much as possible. Obviously, when a released feature's GUI proves to be cumbersome and unproductive, it should be revised. But revised only to minimum extent required. When a new GUI for current features can be justified based on consistency, improved productively and/or accuracy, then an option should be provided to current users to revert to the old GUI if they choose to for at least 1 or 2 releases/updates.
GUI changes should be beta tested by a broad base of REAL experienced users before being released. REAL user testers should be heavily weighted to LONG time users and not just based on younger, inexperienced users with very little investment in time relative to the current GUI.
In GUI software, change for change's sake should be quickly stopped and denied approval for implementation. Yosemite is a classic example of how not to upgrade software. It obviously was not very well tested before release. If there is one, the SW QA dept should be replaced.
The SW Engineering Manager should be fired for approving a Software Specification and GUI Specification that was Yosemite.
Did anyone on the SW Engineering Development team have ANY extensive experience using Mac OS X?
Maverick was a significant change from Mountain Lion but it was still recognizable as a Mac OS.
Yosemite looked like a rejected Windoze OS release.
Being a long time Apple shareholder and a Mac Evangelist since 1984 (even had a Lisa in 1982!), I am deeply concerned that Apple is loosing it's way.
A user friendly, well tested GUI was Apple's discriminator and is what created a loyal user base. Let's hope Apple does not lose sight of their product’s best feature.
