I think performance is a euphemism for "it now works reliably on iOS8 devices". It didn't before...
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Apple Releases iTunes 12.1 With New Yosemite Notification Center Widget
- Thread starter MacRumors
- Start date
- Sort by reaction score
I think performance is a euphemism for "it now works reliably on iOS8 devices". It didn't before...
I hear ya. I had a playlist on my iPad and MBP, with some songs duplicated only in the iPad playlist. I deleted both and created a new playlist on my MBP, which my iPad refused to sync. The annoying things was, that the playlist was listed under the iPad in my MBP iTunes, however nowhere to be found in my actual iPad. After a second forced sync, my iPad froze and had to be restarted. Of course without the playlist.
Two days later, the playlist finally synced, but when pressed the songs to play, the smallish red equilizer like symbol to the right of the song was moving, however the curser on top wasn't and no sound was heard. Restart again, finally everything back in a working order.
Exercise my on Sony Xperia Z3: clicked on iSyncr, selected the playlist I wanted to sync from my MBP and a few minutes later I had everything I wanted on my phone.
Pathetic that nowadays even third party software on a different portable OS works better than the native
OS.But hey, very soon we have emojis
Who's in Charge? What needed fixing and/or new feature added?
Having been a software development engineer and manager for over 20 years and a Mac Evangelist since 1984, I have been very disturbed by the GUI changes that Apple has made to the OS X over the past 5 years.
There appears to have been an invasion of Microsoft SW programmers into the Mac OS X systems SW department.
Any change to an established GUI should be a very critical concern of any Software Manager and only done to fix a major error or to add new features, which should not impact GUIs for current features.
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 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 rogue 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 hours in lost time adjusting the 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. 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 users before being released. REAL users 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.
A user friendly, well tested GUI used to be Apple's strong point and is what created a loyal user base. Let's hope Apple does not lose sight of their best product discriminator.
In GUI software, change for change's sake should be quickly stopped and denied approval for implementation.
Having been a software development engineer and manager for over 20 years and a Mac Evangelist since 1984, I have been very disturbed by the GUI changes that Apple has made to the OS X over the past 5 years.
There appears to have been an invasion of Microsoft SW programmers into the Mac OS X systems SW department.
Any change to an established GUI should be a very critical concern of any Software Manager and only done to fix a major error or to add new features, which should not impact GUIs for current features.
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 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 rogue 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 hours in lost time adjusting the 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. 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 users before being released. REAL users 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.
A user friendly, well tested GUI used to be Apple's strong point and is what created a loyal user base. Let's hope Apple does not lose sight of their best product discriminator.
In GUI software, change for change's sake should be quickly stopped and denied approval for implementation.