dewme

I'm glad to see you hit the industrial design topic very hard. This is one of Apple's core competencies and goes largely unappreciated by those who don't understand full scale product development. Too many neophytes and clueless pundits believe that all the magic occurs in design studio and just automagically transforms into plastic wrapped products neatly packed into tidy white boxes with an embossed Apple logo on them. The great product designers, people like Jony Ive and companies like Apple, don't separate design and operations into walled off enclaves with throw-it-over-the-wall handoffs. They continuously iterate over all phases of the product development cycle from concept, through several design-for attributes, including industrial design, manufacturability (DFM), testability, serviceability, etc.

Viewing design and operations as separate and independent activities is so 1970s. Just look at where software development practice has ended up after 25+ years of believing that design centricity was king. We had structured design, followed by object oriented design, followed by component based design, with GoF design principles thrown in, and some SOLID principles to go with it. Where did all this design-is-king get us in terms of software maturity? How does decades worth of integrated processors produced with horrible security holes, blue screens of death on grandma's laptop, multi-million dollar space probes cratering Mars, an entire generation of defense programs that couldn't get to step 1 because of the prospect of unmanageable defect rates. Maybe design was not really King, but more like a Jack - or a deuce. So where did software development go to soothe their burned egos? DevOps - or development operations, the unification of development (including design of course) and operations. There's reason that companies like Apple can handle huge beta programs, deliver new builds nearly continuously, and address field issues in hours or days versus what used to be weeks or months. Putting together software builds and releases used to be really big deals, now they are routine single click operations with high fidelity traceability as to where all the pieces and parts came from and what test case provided the required verification and validation. Sure, bugs still get out, but when you look at the volume of code that is shipping today versus the defect rates, the improvement is astounding versus the bad old days when design was thought to be our savior.

So yeah, operations is just as important as design, but it's also inseparable from design. 

wood1208 said:

Apple should have offered DTK at lower price and let them keep it. Not sure what Apple will do with returned DTK unless rip off processor,memory,etc from it and use in Macbooks products because of component shortages.

The DTKs were leased equipment, not purchases. In all likelihood, the lease payments are fully tax deductible business expenses for companies who run their development as a business and not a hobby. 

Mr Kiani is exactly correct in stating that the diagnosis of a serious medical condition such as Obstructive Sleep Apnea requires the use of medical grade equipment that has been certified (and quite likely calibrated) for detecting the condition in question. But then he goes on to rail against Apple's pulse oximetry implementation and its limitations when, in fact, Apple has never sought to certify or make any specific claims about the use of their pulse oximetry feature for diagnosing the conditions in question. Basically, he's criticizing Apple for not doing something that Apple specifically and officially claims they are not doing, and rightly, should not be doing at the level of their involvement.   

I do understand Mr Kiani's concerns from the standpoint of defining where devices such as the Apple Watch fall within the larger scope of health care. It's no different than the features in Apple Watch that detect irregular or abnormal heartbeats and heart rates. I have no doubt that many folks who are inside the realm of producing medical grade diagnostic equipment for helping doctors and healthcare professionals diagnose medical conditions have a negative reaction to seeing features in consumer products that may be implicitly seen as being valid medical diagnostic tools by users regardless of the many disclaimers put forth by the device maker. This is a legitimate concern, but it must be put into the broader perspective of individual's participation and awareness of their overall health and wellbeing. 

People are not like a herd of cows whose health, safety, and wellbeing depends on an individual like a medical specialist or doctor who is responsible for their husbandry. Most people are self aware and are responsible for participating in their own health care to a certain extent. If they don't feel well or notice something is "off," i.e., are exhibiting some kind of symptoms, they can and probably should seek the care of a medical professional. Unfortunately there are a lot of symptoms that can go unnoticed by an individual. For example, someone with obstructive sleep apnea may snore very loudly or stop breathing intermittently when they are sleeping. If there is nobody nearby, like a bedmate, to observe the symptoms the underlying condition may go unnoticed and not acted upon, which can lead to other serious health conditions. If their bedmate observes the symptoms, like obnoxious snoring, they can inform the affected person to look into what may be causing the snoring and bring it up with their primary care physician at their next visit.

In the example above is the bedmate a medical grade diagnostician? Unless the bedmate is a medical professional the answer is no. The bedmate is simply an observer who happens to observe something the affected person was unable to detect on their own, in this case because they are sleeping. Even if the bedmate observer was a medical professional they would still steer the affected person towards a medical professional who can properly diagnose the affected person's condition using all of the certified tools at their disposal. There's a huge difference between an observer and a diagnostician. The observer merely collects data. Turning data into information and subsequently turning information into action and response via diagnostic procedures requires additional context and appropriate reactive activities, including the application of medical grade measurement and diagnostic equipment and the consultation with other professionals. 

The Apple Watch is an observer that is capable of capturing, even if on a limited or intermittent basis, health related data that could otherwise go unnoticed by the wearer. No more, no less. The Apple Watch does not elevate the interpretation of the observed data and it most certainly does not attempt to diagnose the underlying condition. As a caring and responsible observer it does steer the wearer towards seeking professional help. When viewing healthcare from a holistic perspective, one that involves personal awareness and participation, and in concert with all of the other formal and professional layers, it's doing exactly what it can do and should do at this point in its evolution. 

All software seems to follow a common lifecycle model over time. As more bugs are addressed by more and more developers who were not part of the original design team it starts to accumulate a lot of cruft and quick fixes and workarounds to meet release deadlines. This accumulation of cruft, crud, and crappy shortsighted quick fixes is collectively known as “technical debt” because the current software team has literally taken out a bad loan to buy a bunch of shitty workarounds that some future team of maintenance developers is going to have to pay for, and pay for at loan shark interest rates.

When developers occasionally grow a little piece of spine they get up in front of management and talk poignantly about the dire need to pay down some of their technical debt, perhaps using “refactoring” or redesign, or god forbid, rearchitecting of the current code base. At some point in the spiel the management team challenges them with something to the effect of “so you’re saying you want us to spend a bunch of man-years of development resources, a boatload of money, and so many millions of dollars, and so many months of schedule to give us a refreshed code base that does pretty much what the old code  does, but without the hanging chads and dingleberries?”  At that point the little piece of developer spine turns to jelly with a “well yeah, pretty much.” So much for grandiose plans. The end result is that not only is the trash can of technical debt kicked further down the road, but the development team is tasked with adding a bunch of new money-making features on top of the shaky foundation that is like a rickety bridge waiting to collapse. Of course the new features introduce more technical debt and have to work around the shortcomings caused by the underlying technical debt. 

It’s rather easy for a startup like Tesla to feel emboldened by their software prowess because they haven’t had time and customer volume enough to suffer the indignities that accumulate over time when you’re serving a billion customers around the world and have the second and third generation removed teams poking into a business-critical code base that is handed down to them, a code base that is tied to business revenue that has to keep flowing no matter what. Designing new software is usually fun and rewarding. Maintaining existing software is usually a grind and a thankless struggle. Technical debt is like a slow growing cancer, but as long as the supply of band-aids, duct tape, and baling wire is cheaper in the short term than excising the tumors they’ll keep adding on more layers of bandages until they are forced to blow it all up and start over again. Or maybe buy a bunch of software and people through an acquisition.        

My main issue with the way that the EU is operating under the DMA, based on my understanding, is that it seems full of holes, subject to personal whims, political, xenophobic, and massively ambiguous. I'm not just poking at it for personal reasons or to take up Apple's side in the ongoing conflict. I've actually followed, worked on, and directly contributed to "Standards" created or initiated in the EU, pre-EU member countries, or internationally. Standards and certification bodies like IEC, CE, TUV, ISO, UL, CSA, etc., add great value and are a lot more than just a set of requirements that have to be met. They are also highly prescriptive in nature so anyone hoping to sell products that meet these standards can build them to be compliant by following the recommendations and establishing quantifiable measures that can be used by producers to ensure that their products meet the standards. There should be no big surprises when the products in question are submitted for compliance testing.

The one thing in common with most of the standards that establish hard requirements is that they are run by NGOs, not politicians or state leaders. Companies like Apple who produce products for international markets need to be able to design products that meet all the standards where they are sold. The DMA from what I can tell provides no prescriptive guidance for product makers to avoid getting "surprised" when they try to sell a product into a location. It's hard to build something to meet requirements that are highly volatile and enforced at the whim of the enforcers.

I'm not saying the EU or DMA are wrong, because every other locale puts similar non-quantitative and highly subjective impediments in place. I'm just saying that it's a tough nut to crack and companies that sell into other markets need to protect themselves from impositions that they cannot predict. So Apple limiting what they sell into various markets is entirely defensible and a pragmatic decision, not a politically motivated one.

Pretty amazing for a 1.0 product ... but the price is going to scare away a lot of regular folks. 

The Settings app has always been challenging. While Apple has made much needed improvements over several releases, it is still quite baffling and lacking a common schema or recognizable hierarchy. Are all settings organized by functionality like Connectivity, Storage, Passwords, Peripherals, etc. Yes and no. There is some notion of functional organization for things like Notifications, Accessibility, and Privacy & Security, but then there's a bunch of stuff organized by feature such as Focus, Siri and Spotlight, Touch ID and Password, and Game Center. The General settings hierarchy appears to be a dumping ground for putting settings that don't fit the weird mix of hierarchies that exists at the uppermost levels. The same can be said of pretty much everything under the User/Apple ID (soon to Account) tree. It's simply a mess, especially at the levels below iCloud. It's half organized by features activated through subscription.

Why aren't all connectivity related settings placed under a common root called something like Connectivity? Why aren't Wi-Fi, Network, Bluetooth, and Private Relay all placed underneath a common connectivity root? Yeah, Private Relay is a paid enhancement with iCloud+, so just gray it out if the user isn't entitled to it. Don't hide it under Account related settings. Is Wi-Fi not considered a network? 

Why is Advanced Data Protection not part of the Security & Privacy hierarchy? Same thing with Hide My Email.

Why is Touch ID and Password not under Account settings or Security and Privacy? Plus, there's a second root called Passwords only two spots away. Hey, why not leave that banana peel right there where it be stepped on so easily? 

I'll stop here because there are way too many points of confusion and randomness to pick on each and every one. One blanket statement I would add is because the Settings app is so convoluted, confusing, and disorganized Apple could, as an act of mercy for its current users, consider allowing more than one sortation option to organize settings in the UI. I'd take a peek at 1Password's sorting options as a pretty good example. Every trip down the Settings path should not be a journey into the unknown. Things like most recently used, most frequently used, and date of access provide a way for users to implicitly establish breadcrumb trails to where they have been before. Things like this won't solve every problem and may be pig lipstick, but they may reduce some of the confusion for some users a little bit, which is a tiny step in the right direction.

I've been faced with very similar issues to what we see in Settings in applications that I have developed and worked on. This is a common challenge. As an engineer and architect I learned that software development engineers and coders are, as a group, often not particularly good at creating excellent user experiences and user interfaces for non-engineer users. This is not derogatory in any way whatsoever. Through experience you need to learn when to wave the white flag and call in the experts. I have no qualms about waving that flag. Common challenges require the expertise of those who know how to go about solving problems in the domain of interest because they keep facing similar problems time and again. This applies to pretty much every problem domain, from carpentry to neurosurgery. The Settings app is exposed to a massive number of users from all walks of life. Being "good enough" or "not bad" or "it doesn't suck" is not acceptable at Apple's position in the world. I'd say that Settings today is in the "it doesn't' suck" category, which is a step up from where it was. But everyone has their own opinion.

Settings needs the attention of UX/UI experts or a team of UX/UI experts who have intimate knowledge of how users interact with user interfaces, workflows, tasks, etc., that are presented in the Settings app on every Apple product that has human interaction. The UX/UI experts should have the final say on what's acceptable and what is not by applying their knowledge, skill, expertise, connections with other members of the development, sales, and product support teams, and by applying verification methods, with feedback, to solving problems of this nature, knowing that perfection is unachievable. While Apple has made significant improvements to Settings over the years, it's still nowhere near where it needs to be, and I'm not talking about cosmetics or aesthetics at all. A great UX/UI team will always find a way to blend the user experience, look & feel, and aesthetics of an app together in a way that make sense and truly connects better with a greater number of users. 

This is a bit of a spin and wordplay because they are focusing primarily on performance and efficiency and glossing over the reality that the size of running applications working sets cannot be ignored. Yes, having very fast backing store improves memory virtualization, i.e., swapping, but it’s still not as fast as having more real memory available.

They can certainly say that they are getting superior performance and efficiency with 8 GB compared to other competing platforms or architectures running with only 8 GB. But if you’re doing an Apple Silicon-to-Apple Silicon comparison and you would benefit by having 16 GB available due to the combined working set of your running applications, the benefits of having more memory available are real and there is no equivalence  between 8 GB and 16 GB.

Apple Silicon effectively rebases my expectations. I already know it’s better on so many levels (but not all) than other platforms. I don’t want to compare it to lesser platforms. Upping the base level Unified Memory to 16 GB would make the Apple Silicon argument even more pronounced, no song and dance required. We’re paying a premium for choosing Apple, so why not make the perceived value and useful lifetime of the products stand out from the crowd even further? Software is not getting smaller.