{ "version": "https://jsonfeed.org/version/1.1", "user_comment": "This feed allows you to read the posts from this site in any feed reader that supports the JSON Feed format. To add this feed to your reader, copy the following URL -- https://furbo.org/feed/json -- and add it your reader.", "next_url": "https://furbo.org/feed/json?paged=2", "home_page_url": "https://furbo.org", "feed_url": "https://furbo.org/feed/json", "language": "en-US", "title": "furbo.org", "description": "by Craig Hockenberry", "icon": "https://furbo.org/wp-content/uploads/2023/04/furbo.png", "items": [ { "id": "https://furbo.org/?p=2773", "url": "https://furbo.org/2024/03/03/tapestry-what-about/", "title": "Tapestry: What About?", "content_html": "\n
On Mastodon, Alex Chaffee points out some of Tapestry’s shortcomings. These are all valid concerns and I’ll deal them individually here (rather than with a long toot thread).
\n\n\n\nBuilding for iOS first is a strategic choice. There is a lot of work to do here, and many new concepts that need to be designed and developed, so we’re picking our battles carefully.
\n\n\n\nPersonally, I’d prefer to do a macOS client first, but iOS is a choice that makes the product available to as many folks as possible.
\n\n\n\nWe also get asked a lot about supporting Android and that’s something, like macOS, that we will look at after we have a strong footing with this new concept.
\n\n\n\nAnother platform we get asked about frequently: can Tapestry be a web app? We covered this in a FAQ, but I’d like to add a little more detail here.
\n\n\n\nThe only way a web app could be done is if there’s a server to marshal requests to the various services. Since we want the privacy and independence of a device-only design, that option is off the table.
\n\n\n\nIf you’re working in a single browser window as a web app, you put all of your code into a single secure JavaScript context. That’s not a problem, but any code you pull in will need things to communicate with all of the services, and in most cases that will leak private authentication data like OAuth/JWT keys and tokens. All it takes is one malicious plug-in to make your life hell.
\n\n\n\nThe root of the problem is that Tapestry’s fundamental design is different than a web browser. The easiest way to think about: it’s an app that asks a bunch of browser tabs if they have anything new to show. Each tab is secure and none of them know what the others are doing. The results that each tab provides are aggregated and displayed to the user.
\n\n\n\nThis design is wholly different from the web we’ve known, but is just as flexible and adaptable. Building a new thing for the community of the open web is what excites me most about this project. Giving folks tools to be creative is what the web has always been about.
\n\n\n\nRight now, the core of Tapestry is closed source. We have put some components up on GitHub and are also fully documenting an open API to that proprietary core. Teaching is a part of that openness.
\n\n\n\nAgain, we are in the very early days of this project and have no idea where things will head. It’s like if you had asked me in 2006 if a shithead would be running the show in 2024.
\n\n\n\nI think it’s important to think about how Netscape Navigator was a proprietary product until Mozilla happened. Establishing a new idea is a first step; letting it flourish is another.
\n\n\n\nAll I can say at this point is that I’m fully committed to letting this idea flourish.
\n\n\n\nThere is no such thing as a proper web scraper for authenticated content. It’s a cat-and-mouse game where the scrapee wins in the end. We have every reason to believe that Facebook or Instagram will go to great lengths to protect “their” data.
\n\n\n\nOn the other hand, if you want to get standardized information from a page, such as OpenGraph, that’s already something we’re doing.
\n\n\n\nThe prototype I built (named Muxer) was able to post to Mastodon and Micro.blog. But it’s a harder problem than you first think.
\n\n\n\nThe issue is that each service has a different set of capabilities. On Bluesky, you can’t post video. On Mastodon, you can post polls. With RSS, you can’t post at all. Size limits and file formats differ wildly (including between Mastodon instances).
\n\n\n\nYou quickly end up in a situation where a user interface gets confusing. For example, you have a video ready to post on Mastodon and decide that you’d also like to send it to Bluesky. As soon as you do that, the post button gets disabled and it’s hard to explain to a user why that happened.
\n\n\n\nIt’s also not clear in my mind if cross-posting between services is a good thing or not. Once you have an app that can display information from many different sources, it quickly gets annoying to see duplicates.
\n\n\n\nAs we learn more about this product, and what people want from it, we’ll have a better idea of how to handle posting.
\n\n\n\nI’m always happy to talk about Tapestry and explain the thought processes behind it. If you have questions or concerns not covered here, please feel free to reach out on Mastodon.
\n\n\n\nAnd, of course, everyone at the Iconfactory would love your support for Project Tapestry.
\n", "content_text": "On Mastodon, Alex Chaffee points out some of Tapestry’s shortcomings. These are all valid concerns and I’ll deal them individually here (rather than with a long toot thread).\n\n\n\niOS-only\n\n\n\nBuilding for iOS first is a strategic choice. There is a lot of work to do here, and many new concepts that need to be designed and developed, so we’re picking our battles carefully.\n\n\n\nPersonally, I’d prefer to do a macOS client first, but iOS is a choice that makes the product available to as many folks as possible.\n\n\n\nWe also get asked a lot about supporting Android and that’s something, like macOS, that we will look at after we have a strong footing with this new concept.\n\n\n\nBut what about the web?\n\n\n\nAnother platform we get asked about frequently: can Tapestry be a web app? We covered this in a FAQ, but I’d like to add a little more detail here. \n\n\n\nThe only way a web app could be done is if there’s a server to marshal requests to the various services. Since we want the privacy and independence of a device-only design, that option is off the table.\n\n\n\nIf you’re working in a single browser window as a web app, you put all of your code into a single secure JavaScript context. That’s not a problem, but any code you pull in will need things to communicate with all of the services, and in most cases that will leak private authentication data like OAuth/JWT keys and tokens. All it takes is one malicious plug-in to make your life hell.\n\n\n\nThe root of the problem is that Tapestry’s fundamental design is different than a web browser. The easiest way to think about: it’s an app that asks a bunch of browser tabs if they have anything new to show. Each tab is secure and none of them know what the others are doing. The results that each tab provides are aggregated and displayed to the user.\n\n\n\nThis design is wholly different from the web we’ve known, but is just as flexible and adaptable. Building a new thing for the community of the open web is what excites me most about this project. Giving folks tools to be creative is what the web has always been about.\n\n\n\nClosed source\n\n\n\nRight now, the core of Tapestry is closed source. We have put some components up on GitHub and are also fully documenting an open API to that proprietary core. Teaching is a part of that openness.\n\n\n\nAgain, we are in the very early days of this project and have no idea where things will head. It’s like if you had asked me in 2006 if a shithead would be running the show in 2024.\n\n\n\nI think it’s important to think about how Netscape Navigator was a proprietary product until Mozilla happened. Establishing a new idea is a first step; letting it flourish is another.\n\n\n\nAll I can say at this point is that I’m fully committed to letting this idea flourish.\n\n\n\nScraping\n\n\n\nThere is no such thing as a proper web scraper for authenticated content. It’s a cat-and-mouse game where the scrapee wins in the end. We have every reason to believe that Facebook or Instagram will go to great lengths to protect “their” data.\n\n\n\nOn the other hand, if you want to get standardized information from a page, such as OpenGraph, that’s already something we’re doing.\n\n\n\nPosting\n\n\n\nThe prototype I built (named Muxer) was able to post to Mastodon and Micro.blog. But it’s a harder problem than you first think.\n\n\n\nThe issue is that each service has a different set of capabilities. On Bluesky, you can’t post video. On Mastodon, you can post polls. With RSS, you can’t post at all. Size limits and file formats differ wildly (including between Mastodon instances).\n\n\n\nYou quickly end up in a situation where a user interface gets confusing. For example, you have a video ready to post on Mastodon and decide that you’d also like to send it to Bluesky. As soon as you do that, the post button gets disabled and it’s hard to explain to a user why that happened.\n\n\n\nIt’s also not clear in my mind if cross-posting between services is a good thing or not. Once you have an app that can display information from many different sources, it quickly gets annoying to see duplicates.\n\n\n\nAs we learn more about this product, and what people want from it, we’ll have a better idea of how to handle posting.\n\n\n\nAnd more\u2026\n\n\n\nI’m always happy to talk about Tapestry and explain the thought processes behind it. If you have questions or concerns not covered here, please feel free to reach out on Mastodon.\n\n\n\nAnd, of course, everyone at the Iconfactory would love your support for Project Tapestry.", "date_published": "2024-03-03T13:46:30-07:00", "date_modified": "2024-03-03T13:46:30-07:00", "authors": [ { "name": "Craig Hockenberry", "url": "https://furbo.org/author/admin/", "avatar": "https://secure.gravatar.com/avatar/646ce3f178af64df9b0bb9d73e31e3bc?s=512&d=mm&r=g" } ], "author": { "name": "Craig Hockenberry", "url": "https://furbo.org/author/admin/", "avatar": "https://secure.gravatar.com/avatar/646ce3f178af64df9b0bb9d73e31e3bc?s=512&d=mm&r=g" }, "tags": [ "Design", "Development" ] }, { "id": "https://furbo.org/?p=2741", "url": "https://furbo.org/2024/01/29/the-next-40/", "title": "The Next 40", "content_html": "\nLast week’s 40th anniversary of the Mac got me thinking. I’ve also been contemplating this week’s release of Apple Vision Pro.
\n\n\n\nIt feels like we’re at a crossroads for platforms, but one that’s impossible to pass.
\n\n\n\nI was one of the folks who bought a Mac in 1984. At the time I was a member of a team building a Unix workstation from the ground up. We had bigger displays, better networking, faster processors, more memory, and larger disks.
\n\n\n\nBut we were all jealous of what the team at Apple had done. That first Mac and its system software was brimming with new user interface ideas and techniques. Better ways of doing everything we had done.
\n\n\n\nAnd you can say the same thing about Apple Vision Pro and visionOS.
\n\n\n\nExcept there is a problem.
\n\n\n\nIf you’re a software developer, the Apple Vision Pro cannot be used standalone for your work. You’ll be able to use it as much as you do an iPad. You can experiment in Playgrounds and build some simple apps, but you’ll quickly hit a wall.
\n\n\n\nThat’s because developers use a lot of processes. And these processes talk to each other in very creative ways. Maybe it’s as simple as creating child processes to handle work. Maybe it’s a more complicated process like a Docker container running a web server that talks to a database process via a Ruby on Rails process. There are processes everywhere you look.
\n\n\n\nAnd in an Apple sandbox, you get one process. You can’t fork
and exec
a child. And if you query the Mach kernel for information about another process, you get back KERN_FAILURE
.
(To get a very good idea of what’s possible at the fringes of a sandbox, take a look at a-Shell on your mobile device. It does an amazing number of things, but you’ll quickly feel frustrated that ps
, kill
, top
, and anything else that deals with processes is missing.)
There is a good reason for apps only having visibility of their own state. Imagine the kind of fingerprinting that Google and Facebook could do by seeing what apps you’re using. We’ve already seen apps trying to do the same thing using URL schemes.
\n\n\n\nWhen my pal John Gruber talks about Macs doing the heavy lifting, it’s not just about complex and resource-intensive tasks. It’s also about the security exposure: the Mac is the only “dangerous” Apple platform.
\n\n\n\nThere is a thing that developers love almost much as processes: windows. We have so damn many. Hundreds on a good day. Thousands on a really good day.
\n\n\n\nAnd this is why I get frustrated every time I see a demo of Apple’s headset. I can easily imagine fitting my work into a space with an infinitely large interaction surface.
\n\n\n\nAs it is now, you get to see a screen or two streamed from your Mac. That will surely improve; probably to the point where you have individual windows in your spatial environment.
\n\n\n\nBut you’ll still be carrying the Mac around to get any work done. Somewhat ironically, the Apple Vision Pro is not doing the heavy lifting, but it will be the thing that’s cumbersome in your daily life.
\n\n\n\nHere’s a comparison of the headset’s carrying case and a MacBook Air:
\n\n\n\n\n\n\n\nThe Apple Vision Pro is almost 15 times taller than the MacBook Air. Even worse, I can’t even close my backpack, much less fit in a laptop:
\n\n\n\n\n\n\n\nAfter the Mac was introduced, you didn’t have to carry around an Apple ][ or Lisa to do software development.
\n\n\n\nYet here we are because the Apple Vision Pro is locked down. It’s being relegated to being a fancy display for software developers. That’s not necessarily a bad thing and there’s no extra cost for a display stand.
\n\n\n\nThis isn’t a sustainable situation for the next 40 years. Without some low-level structural changes in visionOS, it will never thrive as a developer platform. Just as the iPad has not.
\n\n\n\nIt also doesn’t bode well for the Mac. I’m sure Apple can continue to add incremental changes to satisfy developers, but there won’t be anything revolutionary with how we work. There is also little incentive for Apple to change here: you are buying an Apple Vision Pro along with a MacBook, after all.
\n\n\n\nOne of the extrordinary things that happened back in 1984 was the ability to have more than one terminal window. Even though my Mac had to be connected to a VAX 11/780 over a serial cable (sound familiar?), this was a completely new way of working. We were suddenly free of working within the confines of a single 24\u00d780 character display.
\n\n\n\nOnce we broke free of those limitations, things like visual development environments took hold. I’m pretty sure Apple understands the productivity benefits that came along with these changes.
\n\n\n\nAnd here’s the thing: developers don’t come up with these ideas unless they have a place to experiment. Seeing multiple windows that contained code, debugging, and other tools led some folks to start thinking about integrating this environment using the new interaction mechanisms.
\n\n\n\nThose same kind of folks may find inspiration in spatial computing, but will ultimately get thwarted by the restrictions of a single process. An architecture developed for mobile devices with only one app on the screen is now being used for apps on an infinitely large screen.
\n\n\n\nApple Vision Pro is a technical marvel, but ultimately falls short in ways that satisfy the natural curiosity of developers.
\n\n\n\nThat’s a shame. I just hope some smart folks at Apple feel the same frustration I do, because we need a future beyond the Mac.
\n", "content_text": "Last week’s 40th anniversary of the Mac got me thinking. I’ve also been contemplating this week’s release of Apple Vision Pro.\n\n\n\nIt feels like we’re at a crossroads for platforms, but one that’s impossible to pass.\n\n\n\nI was one of the folks who bought a Mac in 1984. At the time I was a member of a team building a Unix workstation from the ground up. We had bigger displays, better networking, faster processors, more memory, and larger disks.\n\n\n\nBut we were all jealous of what the team at Apple had done. That first Mac and its system software was brimming with new user interface ideas and techniques. Better ways of doing everything we had done.\n\n\n\nAnd you can say the same thing about Apple Vision Pro and visionOS.\n\n\n\nExcept there is a problem.\n\n\n\nProcesses\n\n\n\nIf you’re a software developer, the Apple Vision Pro cannot be used standalone for your work. You’ll be able to use it as much as you do an iPad. You can experiment in Playgrounds and build some simple apps, but you’ll quickly hit a wall.\n\n\n\nThat’s because developers use a lot of processes. And these processes talk to each other in very creative ways. Maybe it’s as simple as creating child processes to handle work. Maybe it’s a more complicated process like a Docker container running a web server that talks to a database process via a Ruby on Rails process. There are processes everywhere you look. \n\n\n\nAnd in an Apple sandbox, you get one process. You can’t fork and exec a child. And if you query the Mach kernel for information about another process, you get back KERN_FAILURE.\n\n\n\n(To get a very good idea of what’s possible at the fringes of a sandbox, take a look at a-Shell on your mobile device. It does an amazing number of things, but you’ll quickly feel frustrated that ps, kill, top, and anything else that deals with processes is missing.)\n\n\n\nThere is a good reason for apps only having visibility of their own state. Imagine the kind of fingerprinting that Google and Facebook could do by seeing what apps you’re using. We’ve already seen apps trying to do the same thing using URL schemes.\n\n\n\nWhen my pal John Gruber talks about Macs doing the heavy lifting, it’s not just about complex and resource-intensive tasks. It’s also about the security exposure: the Mac is the only “dangerous” Apple platform.\n\n\n\nWindows\n\n\n\nThere is a thing that developers love almost much as processes: windows. We have so damn many. Hundreds on a good day. Thousands on a really good day.\n\n\n\nAnd this is why I get frustrated every time I see a demo of Apple’s headset. I can easily imagine fitting my work into a space with an infinitely large interaction surface.\n\n\n\nAs it is now, you get to see a screen or two streamed from your Mac. That will surely improve; probably to the point where you have individual windows in your spatial environment.\n\n\n\nBut you’ll still be carrying the Mac around to get any work done. Somewhat ironically, the Apple Vision Pro is not doing the heavy lifting, but it will be the thing that’s cumbersome in your daily life.\n\n\n\nHere’s a comparison of the headset’s carrying case and a MacBook Air:\n\n\n\n11.69″ \u00d7 8.78″ \u00d7 6.5″ vs. 11.97″ \u00d7 8.46″ \u00d7 0.44″\n\n\n\nThe Apple Vision Pro is almost 15 times taller than the MacBook Air. Even worse, I can’t even close my backpack, much less fit in a laptop:\n\n\n\n“You’re going to need a bigger boat.”\n\n\n\nAfter the Mac was introduced, you didn’t have to carry around an Apple ][ or Lisa to do software development.\n\n\n\nYet here we are because the Apple Vision Pro is locked down. It’s being relegated to being a fancy display for software developers. That’s not necessarily a bad thing and there’s no extra cost for a display stand.\n\n\n\nBut\u2026\n\n\n\nThis isn’t a sustainable situation for the next 40 years. Without some low-level structural changes in visionOS, it will never thrive as a developer platform. Just as the iPad has not.\n\n\n\nIt also doesn’t bode well for the Mac. I’m sure Apple can continue to add incremental changes to satisfy developers, but there won’t be anything revolutionary with how we work. There is also little incentive for Apple to change here: you are buying an Apple Vision Pro along with a MacBook, after all.\n\n\n\nOne of the extrordinary things that happened back in 1984 was the ability to have more than one terminal window. Even though my Mac had to be connected to a VAX 11/780 over a serial cable (sound familiar?), this was a completely new way of working. We were suddenly free of working within the confines of a single 24\u00d780 character display.\n\n\n\nOnce we broke free of those limitations, things like visual development environments took hold. I’m pretty sure Apple understands the productivity benefits that came along with these changes.\n\n\n\nAnd here’s the thing: developers don’t come up with these ideas unless they have a place to experiment. Seeing multiple windows that contained code, debugging, and other tools led some folks to start thinking about integrating this environment using the new interaction mechanisms.\n\n\n\nThose same kind of folks may find inspiration in spatial computing, but will ultimately get thwarted by the restrictions of a single process. An architecture developed for mobile devices with only one app on the screen is now being used for apps on an infinitely large screen.\n\n\n\nApple Vision Pro is a technical marvel, but ultimately falls short in ways that satisfy the natural curiosity of developers.\n\n\n\nThat’s a shame. I just hope some smart folks at Apple feel the same frustration I do, because we need a future beyond the Mac.", "date_published": "2024-01-29T10:28:32-07:00", "date_modified": "2024-01-29T10:28:32-07:00", "authors": [ { "name": "Craig Hockenberry", "url": "https://furbo.org/author/admin/", "avatar": "https://secure.gravatar.com/avatar/646ce3f178af64df9b0bb9d73e31e3bc?s=512&d=mm&r=g" } ], "author": { "name": "Craig Hockenberry", "url": "https://furbo.org/author/admin/", "avatar": "https://secure.gravatar.com/avatar/646ce3f178af64df9b0bb9d73e31e3bc?s=512&d=mm&r=g" }, "tags": [ "Development", "Observation" ] }, { "id": "https://furbo.org/?p=2671", "url": "https://furbo.org/2023/09/28/the-timer-in-watchos-10/", "title": "The Timer in watchOS 10", "content_html": "\nThe new visual appearance and functionality of watchOS 10 is a welcome change. There was clearly a lot of design and engineering effort put into this new interface and the improvements are tangible for most apps.
\n\n\n\nUnfortunately, the app that I use the most on the Apple Watch has lost much of its usability, both in functionality and accessibility.
\n\n\n\nI’m talking about the Timer app.
\n\n\n\nThe team designing watchOS clearly knows what it’s doing. Using the infinitely large corners of the Apple Watch display to leverage Fitt’s Law shows remarkable insight. The new gestures, while unfamiliar at first, feel like they will be as transformative as when phones no longer had Home buttons.
\n\n\n\nThe only explanation I can find for the Timer’s design regressions is an unfamiliarity with some use cases. In the following critique, I’ll focus on how the watch is used in the kitchen and how older customers struggle with the new layout. Suggestions will be kept to a minimum: the effort here is to be descriptive, not prescriptive.
\n\n\n\nThe Timer has been my favorite app since it debuted in the first version of watchOS. It was basic: you could only set one timer and you had to do it manually (there were no presets).
\n\n\n\nWhy was this interface so useful to me? Because I spend a lot of time cooking.
\n\n\n\nMy watch became the perfect timer. It went with me wherever I was making a meal. No more situations where you set a reminder in the kitchen and don’t hear it go off because you are outside at the barbecue.
\n\n\n\nThe next version of the Timer added presets for 1, 3, 5, 10, 15, and 30 minutes along with settings for 1 or 2 hours. This, to me, was the pinnacle of its design on watchOS. Why?
\n\n\n\nThose time settings, placed in a neat grid, provided all the functionality I needed. I only used the first six timers, but I used them often.
\n\n\n\nBut more importantly, the navigation of that magic grid could be done without hands. Any cook can tell you that there are times where uncooked food on your hands is either dangerous or messy. Dressing a chicken, gutting a fish, or making meatballs are all times where you will not want to touch an Apple Watch.
\n\n\n\nInstead, you will navigate with your nose.
\n\n\n\nThat’s right, a capacitive screen works with any part of your body. I can easily start a new timer or cancel a ringing timer just by holding it up to my face. And when you’re cooking, you do that often.
\n\n\n\nWhich leads to the next interation of the watchOS Timer. The addition of Recents made getting to the 1/3/5/10/15/30 settings more challenging because scrolling with your nose is significantly more difficult. Thankfully, once you positioned the magic grid on the device, going into and out of timers could be done quickly and easily.
\n\n\n\nAnd the efficency of selecting a timer is very important when you are setting a dozen of them every hour. How can that happen?
\n\n\n\nSo now let’s look at some of the specific things that cooks need from the Timer app. To give you an idea of the basic challenge, you can ask this simple question:
\n\n\n\n\n\n\n\nHow long does it take to carmelize an onion?
The correct answer is: “I have no idea”. There are too many factors involved:
\n\n\n\nWhat you do know is that it will take about 15 minutes for the onion to soften up at a medium heat. And then you check it. And probably lower the heat and set a timer for 10 minutes. And check it again. And then probably do a 3 or 5 minute timer on low heat a couple times. And when that’s done, you go with one minute and do your best to not burn them. This is how you end up setting a dozen timers in an hour.
\n\n\n\nAll cooks have this inherent knowledge: when a recipe says “15 minutes” you know that means “check it at 10 minutes” and go from there. I don’t even trust times on frozen pizzas: are you absolutely sure that your oven temperature is 425\u00ba F?
\n\n\n\nThis is exactly why the magic grid in the Timer app is so important. It has all the common checkpoints a cook needs. It’s also why Recents are a non-feature while cooking: after you’ve done your 5 minute checkpoint and go back to Recents you need a timer for one minute but 5, 30, 15, and 3 are the most recent.
\n\n\n\nAnother aspect to cooking is that you’re typically in a hurry and juggling multiple tasks. Setting a timer manually is much quicker and safer than relying on Siri. A kitchen also tends to be a noisy place, with multiple conversations and background music. If Siri doesn’t understand what you’ve said, you’re going to end up with burnt onions.
\n\n\n\nThe challenges of growing older are numerous, but the one that I struggle with the most is vision. My eyes suck.
\n\n\n\nIf you’re a young designer, you have no idea what’s coming. I didn’t.
\n\n\n\nIt’s common for aging eyes to be affected by presbyopia. The focal difficulties associated with this disease means you have to concentrate more to read small text. That is exacerbated when the text contains repeated symbols. The contrast of the text against a background is also important.
\n\n\n\nIn short, symbols like “01:00” and “10:00” increase cognitive load because they can’t be read at a glance.
\n\n\n\nAlso of note: your health is a much bigger concern as you grow older. You are reminded of your mortality every day when you struggle to put on your socks. The Apple Watch’s health monitoring features become essential as you enter this stage of your life. I’m confident that Apple has a lot of aging users for this device.
\n\n\n\nIt’s likely that the problems faced by a large portion of the customer base aren’t known by a young design team. I’m hoping this essay will help with that.
\n\n\n\nNow that we’ve covered some of the specific needs of old farts and people who like to cook, let’s look at how changes in watchOS 10 affect both functionality and usability for these groups.
\n\n\n\nAs we discuss these changes, I’ll be referring to the image below which shows how things looked before (left) and after (right) the new watchOS version:
\n\n\n\n\n\n\n\nThe root of the problem on watchOS 10 is that setting a timer is now done in a modal presentation (with a close button in the upper-left corner).
\n\n\n\nThis means that no position is maintained between uses: the Recents are always at the top and have the ordering problem noted above. The magic 1/3/5/10/15/30 grid is only accessible by scrolling.
\n\n\n\nThe new UI is impossible to use hands-free. Cooks who want to set or change a timer while deboning a chicken are out of luck.
\n\n\n\nThis problem could be remedied if the last position in the modal view was maintained as in previous versions of watchOS. If maintaining the scroll position is not possible, an affordance to remove or collapse Recents would help by putting the magic 1/3/5/10/15/30 grid at the top of the view.
\n\n\n\nAdditionally, the All Timers list begins with a big plus button. This breaks the muscle memory associated with 1 minute being in the top-left position \u2013 it’s now in the top-right.
\n\n\n\nIn my experience, adding a timer is a rare occurance. I’ve done it twice in the 8 years I have owned an Apple Watch. Both were for laundry: one for a washing cycle and another for a drying cycle.
\n\n\n\nPutting the big plus button at the end of the list, and closer to Edit, feels like a better solution that makes the list more readable and familiar.
\n\n\n\nWhen you compare the screenshots of the previous and current versions you can easily see that watchOS 10 is more consistent. The list is also shorter because favorites have been folded into All Timers. These are both good things.
\n\n\n\nBut the consistency works against me and my failing eyesight. Everything looks the same and it’s difficult to know where I am within the list. (Remember that you only seeing four of the circles on the watch face: there are points while scrolling where you can’t know if you’re in Recents or All Timers.)
\n\n\n\nAs noted above, differentiating between “01:00” and “10:00” takes more effort. Not only is the text smaller, but there’s a lot of extra noise that affects readability. The text in watchOS 9 used “1 MIN” and “10 MIN”, with the numbers presented in an accent color to emphasize the minutes. It was much more readable.
\n\n\n\nThe need for leading and trailing zeros to maintain consistency also leads to a situation where timers that are longer than 59 minutes get smaller text that’s harder to read. Luckily, the need for a 10 hour timer in my life is unlikely, so I don’t have to deal with reading a tiny “10:00:00” and “01:00:00”.
\n\n\n\nThe leading and trailing zeros made some sense in watchOS 9’s Favorites and Recents list where each button’s label aligned well with its siblings. But with the grid layout in watchOS 10, the need for zero padding is not necessary and just feels like visual noise.
\n\n\n\n(Note that users with VoiceOver hear “one minute”, not “zero one colon zero zero” or “one minute zero seconds”. Visual noise for normal eyesight should be reduced just as it is with the spoken audio.)
\n\n\n\nMy first thought was that these changes on watchOS were an effort to get consistency across platforms, especially with the addition of multiple timers in iOS 17. This does not appear to be the case:
\n\n\n\n\n\n\n\nI have also wondered why seconds are shown as a part of the standard format on watchOS. I’m sure there are people that set timers for 12 minutes and 34 seconds, but they are certainly the outliers. When was the last time you had a pizza that needed 11:45 in the oven or a load of laundry that took 45:11?
\n\n\n\nPeople think in minutes, so minimize their cognitive load by focusing on that unit of time. By doing this, you could improve accessibility for everyone by using BIGGER NUMBERS on a small screen.
\n\n\n\n(Seconds could be handled in a way similar to the new Modular Ultra watch face. Dimming the trailing seconds would allow someone to know that “1:23” is one minute and 23 seconds and not one hour and 23 minutes. Again, minutes are the thing that’s most important to people.)
\n\n\n\nIn summary, this is a rare case where less consistency would make for a better and more accessible user interface.
\n\n\n\nOne final accessibility problem in the new Timer app is when one completes. Here is what you see, both with and without accessibility features turned on:
\n\n\n\n\n\n\n\nThe image on the left has bold text turned on with the default text size. On the right, you see what happens when you make the text size larger and increase the contrast.
\n\n\n\nThe timer length on this screen is not accessible and cannot be improved with accessibility settings. The dim text on a bright orange background is incredibly hard for me to read. I think the information hierarchy is the root of the problem.
\n\n\n\n“Done” is not the most important thing on this screen when you have a timer that completes: the length of what just finished is most significant. People will know what a bright orange screen and ringing means. They may not know which timer fired, and that can only be determined by reading “1 MIN” in dimmed out text at a much smaller size.
\n\n\n\nWhile counting, the current state of the timer belongs in large white text. When the count is complete, the length of the timer that finished has that same level of importance. This significance increases when you have multiple timers.
\n\n\n\n(Confusing timers with similar lengths is an easy thing to do: I nearly screwed up two COVID tests at a time when they were in extremely short supply. This happened because I didn’t notice the “5 MIN” and “15 MIN” text.)
\n\n\n\nAt least the timer text in the screenshots above is not “01:00”. Please don’t make this consistent, too.
\n\n\n\nI’m honestly not looking forward to the next year with the Timer app. It’s going to be an irritation dozens of times every day.
\n\n\n\nMy only hope is the other great improvements in watchOS 10, especially with workouts and activity tracking, will make up for it. 🤞
\n\n\n\nIf you need to get in touch with me about any of this, there’s FB13212554. If you’re a developer who feels similarly about these regressions, please dupe this feedback (it’s a copy of this blog post). Otherwise, you can send your comments to Apple directly.
\n", "content_text": "The new visual appearance and functionality of watchOS 10 is a welcome change. There was clearly a lot of design and engineering effort put into this new interface and the improvements are tangible for most apps.\n\n\n\nUnfortunately, the app that I use the most on the Apple Watch has lost much of its usability, both in functionality and accessibility.\n\n\n\nI’m talking about the Timer app.\n\n\n\nThe team designing watchOS clearly knows what it’s doing. Using the infinitely large corners of the Apple Watch display to leverage Fitt’s Law shows remarkable insight. The new gestures, while unfamiliar at first, feel like they will be as transformative as when phones no longer had Home buttons.\n\n\n\nThe only explanation I can find for the Timer’s design regressions is an unfamiliarity with some use cases. In the following critique, I’ll focus on how the watch is used in the kitchen and how older customers struggle with the new layout. Suggestions will be kept to a minimum: the effort here is to be descriptive, not prescriptive.\n\n\n\nHistory\n\n\n\nThe Timer has been my favorite app since it debuted in the first version of watchOS. It was basic: you could only set one timer and you had to do it manually (there were no presets).\n\n\n\nWhy was this interface so useful to me? Because I spend a lot of time cooking.\n\n\n\nMy watch became the perfect timer. It went with me wherever I was making a meal. No more situations where you set a reminder in the kitchen and don’t hear it go off because you are outside at the barbecue.\n\n\n\nThe next version of the Timer added presets for 1, 3, 5, 10, 15, and 30 minutes along with settings for 1 or 2 hours. This, to me, was the pinnacle of its design on watchOS. Why?\n\n\n\nThose time settings, placed in a neat grid, provided all the functionality I needed. I only used the first six timers, but I used them often.\n\n\n\nBut more importantly, the navigation of that magic grid could be done without hands. Any cook can tell you that there are times where uncooked food on your hands is either dangerous or messy. Dressing a chicken, gutting a fish, or making meatballs are all times where you will not want to touch an Apple Watch.\n\n\n\nInstead, you will navigate with your nose.\n\n\n\nThat’s right, a capacitive screen works with any part of your body. I can easily start a new timer or cancel a ringing timer just by holding it up to my face. And when you’re cooking, you do that often.\n\n\n\nWhich leads to the next interation of the watchOS Timer. The addition of Recents made getting to the 1/3/5/10/15/30 settings more challenging because scrolling with your nose is significantly more difficult. Thankfully, once you positioned the magic grid on the device, going into and out of timers could be done quickly and easily.\n\n\n\nAnd the efficency of selecting a timer is very important when you are setting a dozen of them every hour. How can that happen?\n\n\n\nCooking Times\n\n\n\nSo now let’s look at some of the specific things that cooks need from the Timer app. To give you an idea of the basic challenge, you can ask this simple question:\n\n\n\nHow long does it take to carmelize an onion?\n\n\n\nThe correct answer is: “I have no idea”. There are too many factors involved:\n\n\n\nHow much water content is in the onion?How large is the onion?What’s the ambient temperature in the kitchen?What kind of pan are you using?What’s your current elevation?\n\n\n\nWhat you do know is that it will take about 15 minutes for the onion to soften up at a medium heat. And then you check it. And probably lower the heat and set a timer for 10 minutes. And check it again. And then probably do a 3 or 5 minute timer on low heat a couple times. And when that’s done, you go with one minute and do your best to not burn them. This is how you end up setting a dozen timers in an hour.\n\n\n\nAll cooks have this inherent knowledge: when a recipe says “15 minutes” you know that means “check it at 10 minutes” and go from there. I don’t even trust times on frozen pizzas: are you absolutely sure that your oven temperature is 425\u00ba F?\n\n\n\nThis is exactly why the magic grid in the Timer app is so important. It has all the common checkpoints a cook needs. It’s also why Recents are a non-feature while cooking: after you’ve done your 5 minute checkpoint and go back to Recents you need a timer for one minute but 5, 30, 15, and 3 are the most recent.\n\n\n\nAnother aspect to cooking is that you’re typically in a hurry and juggling multiple tasks. Setting a timer manually is much quicker and safer than relying on Siri. A kitchen also tends to be a noisy place, with multiple conversations and background music. If Siri doesn’t understand what you’ve said, you’re going to end up with burnt onions. \n\n\n\nGrowing Older\n\n\n\nThe challenges of growing older are numerous, but the one that I struggle with the most is vision. My eyes suck.\n\n\n\nIf you’re a young designer, you have no idea what’s coming. I didn’t.\n\n\n\nIt’s common for aging eyes to be affected by presbyopia. The focal difficulties associated with this disease means you have to concentrate more to read small text. That is exacerbated when the text contains repeated symbols. The contrast of the text against a background is also important.\n\n\n\nIn short, symbols like “01:00” and “10:00” increase cognitive load because they can’t be read at a glance.\n\n\n\nAlso of note: your health is a much bigger concern as you grow older. You are reminded of your mortality every day when you struggle to put on your socks. The Apple Watch’s health monitoring features become essential as you enter this stage of your life. I’m confident that Apple has a lot of aging users for this device.\n\n\n\nIt’s likely that the problems faced by a large portion of the customer base aren’t known by a young design team. I’m hoping this essay will help with that.\n\n\n\nThe Comparison\n\n\n\nNow that we’ve covered some of the specific needs of old farts and people who like to cook, let’s look at how changes in watchOS 10 affect both functionality and usability for these groups.\n\n\n\nAs we discuss these changes, I’ll be referring to the image below which shows how things looked before (left) and after (right) the new watchOS version:\n\n\n\nThe interface for picking a timer on watchOS 9 (left) and watchOS 10 (right)\n\n\n\nFunctionality\n\n\n\nThe root of the problem on watchOS 10 is that setting a timer is now done in a modal presentation (with a close button in the upper-left corner).\n\n\n\nThis means that no position is maintained between uses: the Recents are always at the top and have the ordering problem noted above. The magic 1/3/5/10/15/30 grid is only accessible by scrolling.\n\n\n\nThe new UI is impossible to use hands-free. Cooks who want to set or change a timer while deboning a chicken are out of luck.\n\n\n\nThis problem could be remedied if the last position in the modal view was maintained as in previous versions of watchOS. If maintaining the scroll position is not possible, an affordance to remove or collapse Recents would help by putting the magic 1/3/5/10/15/30 grid at the top of the view.\n\n\n\nAdditionally, the All Timers list begins with a big plus button. This breaks the muscle memory associated with 1 minute being in the top-left position \u2013 it’s now in the top-right.\n\n\n\nIn my experience, adding a timer is a rare occurance. I’ve done it twice in the 8 years I have owned an Apple Watch. Both were for laundry: one for a washing cycle and another for a drying cycle.\n\n\n\nPutting the big plus button at the end of the list, and closer to Edit, feels like a better solution that makes the list more readable and familiar.\n\n\n\nAccessibility\n\n\n\nWhen you compare the screenshots of the previous and current versions you can easily see that watchOS 10 is more consistent. The list is also shorter because favorites have been folded into All Timers. These are both good things.\n\n\n\nBut the consistency works against me and my failing eyesight. Everything looks the same and it’s difficult to know where I am within the list. (Remember that you only seeing four of the circles on the watch face: there are points while scrolling where you can’t know if you’re in Recents or All Timers.)\n\n\n\nAs noted above, differentiating between “01:00” and “10:00” takes more effort. Not only is the text smaller, but there’s a lot of extra noise that affects readability. The text in watchOS 9 used “1 MIN” and “10 MIN”, with the numbers presented in an accent color to emphasize the minutes. It was much more readable.\n\n\n\nThe need for leading and trailing zeros to maintain consistency also leads to a situation where timers that are longer than 59 minutes get smaller text that’s harder to read. Luckily, the need for a 10 hour timer in my life is unlikely, so I don’t have to deal with reading a tiny “10:00:00” and “01:00:00”.\n\n\n\nThe leading and trailing zeros made some sense in watchOS 9’s Favorites and Recents list where each button’s label aligned well with its siblings. But with the grid layout in watchOS 10, the need for zero padding is not necessary and just feels like visual noise.\n\n\n\n(Note that users with VoiceOver hear “one minute”, not “zero one colon zero zero” or “one minute zero seconds”. Visual noise for normal eyesight should be reduced just as it is with the spoken audio.)\n\n\n\nMy first thought was that these changes on watchOS were an effort to get consistency across platforms, especially with the addition of multiple timers in iOS 17. This does not appear to be the case:\n\n\n\nThe Clock app on iOS 17 showing how timers are formatted in various contexts.\n\n\n\nI have also wondered why seconds are shown as a part of the standard format on watchOS. I’m sure there are people that set timers for 12 minutes and 34 seconds, but they are certainly the outliers. When was the last time you had a pizza that needed 11:45 in the oven or a load of laundry that took 45:11?\n\n\n\nPeople think in minutes, so minimize their cognitive load by focusing on that unit of time. By doing this, you could improve accessibility for everyone by using BIGGER NUMBERS on a small screen.\n\n\n\n(Seconds could be handled in a way similar to the new Modular Ultra watch face. Dimming the trailing seconds would allow someone to know that “1:23” is one minute and 23 seconds and not one hour and 23 minutes. Again, minutes are the thing that’s most important to people.)\n\n\n\nIn summary, this is a rare case where less consistency would make for a better and more accessible user interface.\n\n\n\nOne final accessibility problem in the new Timer app is when one completes. Here is what you see, both with and without accessibility features turned on:\n\n\n\nBold text in the default size (left) and with increased contrast and size (right)\n\n\n\nThe image on the left has bold text turned on with the default text size. On the right, you see what happens when you make the text size larger and increase the contrast.\n\n\n\nThe timer length on this screen is not accessible and cannot be improved with accessibility settings. The dim text on a bright orange background is incredibly hard for me to read. I think the information hierarchy is the root of the problem.\n\n\n\n“Done” is not the most important thing on this screen when you have a timer that completes: the length of what just finished is most significant. People will know what a bright orange screen and ringing means. They may not know which timer fired, and that can only be determined by reading “1 MIN” in dimmed out text at a much smaller size. \n\n\n\nWhile counting, the current state of the timer belongs in large white text. When the count is complete, the length of the timer that finished has that same level of importance. This significance increases when you have multiple timers.\n\n\n\n(Confusing timers with similar lengths is an easy thing to do: I nearly screwed up two COVID tests at a time when they were in extremely short supply. This happened because I didn’t notice the “5 MIN” and “15 MIN” text.)\n\n\n\nAt least the timer text in the screenshots above is not “01:00”. Please don’t make this consistent, too.\n\n\n\nConclusion\n\n\n\nI’m honestly not looking forward to the next year with the Timer app. It’s going to be an irritation dozens of times every day.\n\n\n\nMy only hope is the other great improvements in watchOS 10, especially with workouts and activity tracking, will make up for it. 🤞\n\n\n\nIf you need to get in touch with me about any of this, there’s FB13212554. If you’re a developer who feels similarly about these regressions, please dupe this feedback (it’s a copy of this blog post). Otherwise, you can send your comments to Apple directly.", "date_published": "2023-09-28T14:16:20-07:00", "date_modified": "2023-09-28T16:28:52-07:00", "authors": [ { "name": "Craig Hockenberry", "url": "https://furbo.org/author/admin/", "avatar": "https://secure.gravatar.com/avatar/646ce3f178af64df9b0bb9d73e31e3bc?s=512&d=mm&r=g" } ], "author": { "name": "Craig Hockenberry", "url": "https://furbo.org/author/admin/", "avatar": "https://secure.gravatar.com/avatar/646ce3f178af64df9b0bb9d73e31e3bc?s=512&d=mm&r=g" }, "tags": [ "Design" ] }, { "id": "https://furbo.org/?p=2652", "url": "https://furbo.org/2023/07/09/an-alerting-vista-of-sonoma/", "title": "An Alerting Vista of Sonoma", "content_html": "\nThere’s a new “feature” in Sonoma, and no one besides Apple is quite sure what it is.
\n\n\n\nAlerts for deprecated APIs are now appearing frequently. Sometimes when you launch an app, and sometimes at random. Here are three I got the other day after waking a MacBook from sleep:
\n\n\n\n\n\n\n\nFrom a UI point-of-view, these alerts have serious issues:
\n\n\n\nBut the UI is just the beginning of the fun. Once the developer is notified, the lack of information for this “feature” prevents the deprecation from being addressed.
\n\n\n\nThis alert is mentioned in the release notes for the first beta for Sonoma. The brevity of that note is surprising for such a prominent and important addition to macOS.
\n\n\n\nI suspect that the brevity of the alert’s text is to shield the customer from unfamiliar terminology and complexity. It’s like a check engine light in your car: it comes on and you know to get to a mechanic ASAP.
\n\n\n\nWhen you get to the mechanic, they have diagnostic tools that let them understand what’s wrong (the engine control unit will typically store a unique code).
\n\n\n\nThe difference with this “feature” is that folks like me are the mechanics and we have no diagnostic code. Supposedly, this alert should only appear with the use of ATS or ATSUI (per the release notes), but I find it hard to believe that modern system framework components shown above are using Apple Type Services that were replaced 13 years ago. But maybe they are – we all embed frameworks into our apps, some where we have source code, others where we do not.
\n\n\n\nThe alerts also have another hideous “feature”. They turn themselves off as soon as you hit the OK button. They never repeat, so it’s impossible to bisect the code to find and verify a fix.
\n\n\n\nIt’s like having your check engine like go off the next time you start the car, and the diagnostic code being removed by the time you get to the repair shop. A developer’s reaction to these reports will be the same as your local mechanic: “I don’t know what’s wrong. Good luck.”
\n\n\n\nIf Apple wants developers to repair these deprecations they need to make major changes:
\n\n\n\nWithout these changes a Mac user’s future is one with a lot of crashes caused by deprecated code.
\n\n\n\nNOTE: This blog post has been submitted as feedback. If you find this situation intolerable, please submit a duplicate titled “Mysterious deprecation alerts in Sonoma” with a reference to FB12560999 and a link to this blog post.
\n", "content_text": "There’s a new “feature” in Sonoma, and no one besides Apple is quite sure what it is.\n\n\n\nAlerts for deprecated APIs are now appearing frequently. Sometimes when you launch an app, and sometimes at random. Here are three I got the other day after waking a MacBook from sleep:\n\n\n\nMysterious Alerts.\n\n\n\nFrom a UI point-of-view, these alerts have serious issues:\n\n\n\nThey are scary and not actionable.The only unique information is the title. The name, however, is not something I recognize.I know what a deprecated API is and how its removal can be a bad thing, but ordinary users won’t.There is no mention of what API caused the alert.I’m advised to contact the developer for an updated version, but there is no information on who that developer is. (In the screenshot above, I’m assuming the developer is Apple itself, so I notified them with FB12560773, FB12560774, FB12560776).\n\n\n\nBut the UI is just the beginning of the fun. Once the developer is notified, the lack of information for this “feature” prevents the deprecation from being addressed.\n\n\n\nThis alert is mentioned in the release notes for the first beta for Sonoma. The brevity of that note is surprising for such a prominent and important addition to macOS.\n\n\n\nI suspect that the brevity of the alert’s text is to shield the customer from unfamiliar terminology and complexity. It’s like a check engine light in your car: it comes on and you know to get to a mechanic ASAP.\n\n\n\nWhen you get to the mechanic, they have diagnostic tools that let them understand what’s wrong (the engine control unit will typically store a unique code).\n\n\n\nThe difference with this “feature” is that folks like me are the mechanics and we have no diagnostic code. Supposedly, this alert should only appear with the use of ATS or ATSUI (per the release notes), but I find it hard to believe that modern system framework components shown above are using Apple Type Services that were replaced 13 years ago. But maybe they are – we all embed frameworks into our apps, some where we have source code, others where we do not.\n\n\n\nThe alerts also have another hideous “feature”. They turn themselves off as soon as you hit the OK button. They never repeat, so it’s impossible to bisect the code to find and verify a fix.\n\n\n\nIt’s like having your check engine like go off the next time you start the car, and the diagnostic code being removed by the time you get to the repair shop. A developer’s reaction to these reports will be the same as your local mechanic: “I don’t know what’s wrong. Good luck.”\n\n\n\nIf Apple wants developers to repair these deprecations they need to make major changes:\n\n\n\nDocument the behavior, including all of the APIs that trigger it.Tell developers if this is something that will only appear in the beta or if it will be a part of the final release.Give the customer something to work with when communicating with the developer. A diagnostic code at a minimum.Log information about what caused the issue: remember that it may not be the developer’s own code triggering the alert. Plugins, embedded libraries, and external frameworks should be a part of the log. These logs should be available to customers so they can provide them to developers.Give developers a way to reset the alerts. Make fixes testable.\n\n\n\nWithout these changes a Mac user’s future is one with a lot of crashes caused by deprecated code.\n\n\n\nNOTE: This blog post has been submitted as feedback. If you find this situation intolerable, please submit a duplicate titled “Mysterious deprecation alerts in Sonoma” with a reference to FB12560999 and a link to this blog post.", "date_published": "2023-07-09T12:38:16-07:00", "date_modified": "2023-07-10T09:15:22-07:00", "authors": [ { "name": "Craig Hockenberry", "url": "https://furbo.org/author/admin/", "avatar": "https://secure.gravatar.com/avatar/646ce3f178af64df9b0bb9d73e31e3bc?s=512&d=mm&r=g" } ], "author": { "name": "Craig Hockenberry", "url": "https://furbo.org/author/admin/", "avatar": "https://secure.gravatar.com/avatar/646ce3f178af64df9b0bb9d73e31e3bc?s=512&d=mm&r=g" }, "tags": [ "Development" ] }, { "id": "https://furbo.org/?p=2625", "url": "https://furbo.org/2023/04/12/announcing-blank/", "title": "Announcing Blank", "content_html": "\nI’m happy to announce the release of a new tvOS app called Blank. It turns your screen black and keeps it that way until you press any button on a remote. Seriously, that’s all it does. Here’s the screen you see when you launch the app for the first time:
\n\n\n\n\n\n\n\nThat second paragraph hints at why this is important, despite the app’s simplicity.
\n\n\n\nAs you get older, a good night’s sleep becomes harder to achieve. One thing that works well for my wife and me is to lower light levels before bedtime.
\n\n\n\nThere has been scientific evidence of this since early in the last decade. Bright light can change your circadian rhythm and affect melatonin production, which can “potentially impact sleep, thermoregulation, blood pressure, and glucose homeostasis.”.
\n\n\n\nA big ass screen in the living room makes this hard to achieve. If you want to listen to music or a podcast before going to bed, it’s impossible to avoid a bright now playing screen or animated screen saver.
\n\n\n\nSo I wrote Blank as a way to address this problem. Of course, it’s FREE so people besides me and my wife can benefit from it.
\n\n\n\nThe first version I submitted didn’t meet Guideline 4.2 for “Design – Minimum Functionality”. Understandable, because this app was basically the “anti-flashlight” and we all know how that played out.
\n\n\n\nI took this initial rejection in stride and started working on an update that added some minimal functionality.
\n\n\n\nWhen you launch the app, or press any button on the remote, you get a screen with an inspirational quote. After you’ve had time to read it, the message disappears, and the screen goes black. It’s a nice addition and folks who are using the app love it.
\n\n\n\nI’m glad I did this extra work, and it’s a case where App Review helps a developer improve their product. Here’s what the quote screen looks like:
\n\n\n\n\n\n\n\nAfter some back-and-forth with App Review, the app was approved with these changes. Yay!
\n\n\n\nAn additional benefit became apparent after we started using Blank: it significantly lowers the energy consumption of the screen.
\n\n\n\nAll modern TVs have circuits that detect a blank signal and turn off LEDs to reduce the power required by the device. If you’ve ever felt heat coming off your big screen, Blank makes that go away.
\n\n\n\nSo besides improving your sleep, you’re also helping out our ever warming planet.
\n\n\n\nSo there you have it: another addition to our ever growing list of “little apps”. Just open up the App Store on your Apple TV, search for Blank, and click to download the app for FREE.
\n\n\n\nSimple, beautiful, classic. Enjoy!
\n", "content_text": "I’m happy to announce the release of a new tvOS app called Blank. It turns your screen black and keeps it that way until you press any button on a remote. Seriously, that’s all it does. Here’s the screen you see when you launch the app for the first time:\n\n\n\n\n\n\n\nThat second paragraph hints at why this is important, despite the app’s simplicity.\n\n\n\nSleeping Well\n\n\n\nAs you get older, a good night’s sleep becomes harder to achieve. One thing that works well for my wife and me is to lower light levels before bedtime.\n\n\n\nThere has been scientific evidence of this since early in the last decade. Bright light can change your circadian rhythm and affect melatonin production, which can “potentially impact sleep, thermoregulation, blood pressure, and glucose homeostasis.”. \n\n\n\nA big ass screen in the living room makes this hard to achieve. If you want to listen to music or a podcast before going to bed, it’s impossible to avoid a bright now playing screen or animated screen saver.\n\n\n\nSo I wrote Blank as a way to address this problem. Of course, it’s FREE so people besides me and my wife can benefit from it.\n\n\n\nNew & Improved\n\n\n\nThe first version I submitted didn’t meet Guideline 4.2 for “Design – Minimum Functionality”. Understandable, because this app was basically the “anti-flashlight” and we all know how that played out.\n\n\n\nI took this initial rejection in stride and started working on an update that added some minimal functionality.\n\n\n\nWhen you launch the app, or press any button on the remote, you get a screen with an inspirational quote. After you’ve had time to read it, the message disappears, and the screen goes black. It’s a nice addition and folks who are using the app love it.\n\n\n\nI’m glad I did this extra work, and it’s a case where App Review helps a developer improve their product. Here’s what the quote screen looks like:\n\n\n\n\n\n\n\nAfter some back-and-forth with App Review, the app was approved with these changes. Yay!\n\n\n\nBut That’s Not All!\n\n\n\nAn additional benefit became apparent after we started using Blank: it significantly lowers the energy consumption of the screen.\n\n\n\nAll modern TVs have circuits that detect a blank signal and turn off LEDs to reduce the power required by the device. If you’ve ever felt heat coming off your big screen, Blank makes that go away.\n\n\n\nSo besides improving your sleep, you’re also helping out our ever warming planet.\n\n\n\nThere Is None More Black\n\n\n\nSo there you have it: another addition to our ever growing list of “little apps”. Just open up the App Store on your Apple TV, search for Blank, and click to download the app for FREE.\n\n\n\n Simple, beautiful, classic. Enjoy!", "date_published": "2023-04-12T08:47:55-07:00", "date_modified": "2023-04-12T08:49:55-07:00", "authors": [ { "name": "Craig Hockenberry", "url": "https://furbo.org/author/admin/", "avatar": "https://secure.gravatar.com/avatar/646ce3f178af64df9b0bb9d73e31e3bc?s=512&d=mm&r=g" } ], "author": { "name": "Craig Hockenberry", "url": "https://furbo.org/author/admin/", "avatar": "https://secure.gravatar.com/avatar/646ce3f178af64df9b0bb9d73e31e3bc?s=512&d=mm&r=g" }, "tags": [ "Miscellaneous" ] }, { "id": "https://furbo.org/?p=2605", "url": "https://furbo.org/2023/01/15/the-shit-show/", "title": "The Shit Show", "content_html": "\nWell, it happened.
\n\n\n\nWe knew it was coming.
\n\n\n\nA prick pulled the plug. And what bothers me most about it is how Phony Stark did it.
\n\n\n\nMy mom passed away just before Christmas. Her decline was something everyone in the family saw coming and we prepared for her demise. It still hurts like hell, but she left with love and dignity. That makes all the difference when it comes to coping with loss.
\n\n\n\nTwitterrific is something that we’ve all poured our love into for the past 16 years. I’m not usually one to toot my own horn, but we literally crafted the early experience on the service. We often hear that folks joined up because of our app. Our work was definitive and groundbreaking. We loved this app like I loved my mom.
\n\n\n\n(Note today’s date and the one on our announcement – the fuckwads missed our 16th anniversary by a couple of days! King Shithead probably thought Friday the 13th was lol. I’d love some proof that the API went down at 04:20 in UTC +1.)
\n\n\n\nLike my mom, the API has been declining for awhile. Endpoints were removed, new features were unavailable to third parties, and rate limiting restricted what we could do. And like my mom, we struggled on and did the best we could, trying to stay upbeat about it all.
\n\n\n\nWhat bothers me about Twitterrific’s final day is that it was not dignified. There was no advance notice for its creators, customers just got a weird error, and no one is explaining what’s going on. We had no chance to thank customers who have been with us for over a decade. Instead, it’s just another scene in their ongoing shit show.
\n\n\n\nBut I guess that’s what you should expect from a shitty person.
\n\n\n\nPersonally, I’m done. And with a vengeance.
\n\n\n\nFirst, arrogant bastards love seeing their names on tweets and other media. I want to starve him of the things that money can’t buy: respect and attention. Do the same by simply ignoring him and his kingdom.
\n\n\n\nSecondly, for the past several months I’ve been thinking about where we go from here. When you see decline, you plan for a demise. It was the last thing mom taught me.
\n\n\n\nI’ve been active on Mastodon since the billionaire bozo took over. And it makes me think.
\n\n\n\nOne thing I’ve noticed is that everyone is going to great lengths to make something that replaces the clients we’ve known for years. That’s an excellent goal that eases a transition in the short-term, but ignores how a new open standard (ActivityPub) can be leveraged in new and different ways.
\n\n\n\nFederation exposes a lot of different data sources that you’d want to follow. Not all of these sources will be Mastodon instances: you may want to stay up-to-date with someone’s Micro.blog, or maybe another person’s Tumblr, or someone else’s photo feed. There are many apps and servers for you to choose from.
\n\n\n\nIt feels like the time is right for a truly universal timeline. That notion excites me like the first time I posted XML status to an endpoint.
\n\n\n\nOne thing I remember from these early days: no one had any idea what they were doing. It was all new and things like @screen_name, #hashtags, or RT hadn’t been invented yet. Heck, we didn’t even call them “tweets” or use a bird icon at first! The best ideas came from people using the service: all of the things mentioned above grew organically from a need.
\n\n\n\nThat’s where I want to be in the future. Exploring unknown territory that empowers others and adapts to the needs of a community.
\n\n\n\nThere’s no sense in clinging to the personal whims of a clown leading a shit show. Especially when his circus will end up being a $44 billion version of MySpace.
\n", "content_text": "Well, it happened.\n\n\n\nWe knew it was coming.\n\n\n\nA prick pulled the plug. And what bothers me most about it is how Phony Stark did it.\n\n\n\nMy mom passed away just before Christmas. Her decline was something everyone in the family saw coming and we prepared for her demise. It still hurts like hell, but she left with love and dignity. That makes all the difference when it comes to coping with loss.\n\n\n\nTwitterrific is something that we’ve all poured our love into for the past 16 years. I’m not usually one to toot my own horn, but we literally crafted the early experience on the service. We often hear that folks joined up because of our app. Our work was definitive and groundbreaking. We loved this app like I loved my mom.\n\n\n\n(Note today’s date and the one on our announcement – the fuckwads missed our 16th anniversary by a couple of days! King Shithead probably thought Friday the 13th was lol. I’d love some proof that the API went down at 04:20 in UTC +1.)\n\n\n\nLike my mom, the API has been declining for awhile. Endpoints were removed, new features were unavailable to third parties, and rate limiting restricted what we could do. And like my mom, we struggled on and did the best we could, trying to stay upbeat about it all.\n\n\n\nWhat bothers me about Twitterrific’s final day is that it was not dignified. There was no advance notice for its creators, customers just got a weird error, and no one is explaining what’s going on. We had no chance to thank customers who have been with us for over a decade. Instead, it’s just another scene in their ongoing shit show.\n\n\n\nBut I guess that’s what you should expect from a shitty person.\n\n\n\nPersonally, I’m done. And with a vengeance.\n\n\n\nFirst, arrogant bastards love seeing their names on tweets and other media. I want to starve him of the things that money can’t buy: respect and attention. Do the same by simply ignoring him and his kingdom.\n\n\n\nSecondly, for the past several months I’ve been thinking about where we go from here. When you see decline, you plan for a demise. It was the last thing mom taught me.\n\n\n\nI’ve been active on Mastodon since the billionaire bozo took over. And it makes me think.\n\n\n\nOne thing I’ve noticed is that everyone is going to great lengths to make something that replaces the clients we’ve known for years. That’s an excellent goal that eases a transition in the short-term, but ignores how a new open standard (ActivityPub) can be leveraged in new and different ways.\n\n\n\nFederation exposes a lot of different data sources that you’d want to follow. Not all of these sources will be Mastodon instances: you may want to stay up-to-date with someone’s Micro.blog, or maybe another person’s Tumblr, or someone else’s photo feed. There are many apps and servers for you to choose from.\n\n\n\nIt feels like the time is right for a truly universal timeline. That notion excites me like the first time I posted XML status to an endpoint.\n\n\n\nOne thing I remember from these early days: no one had any idea what they were doing. It was all new and things like @screen_name, #hashtags, or RT hadn’t been invented yet. Heck, we didn’t even call them “tweets” or use a bird icon at first! The best ideas came from people using the service: all of the things mentioned above grew organically from a need.\n\n\n\nThat’s where I want to be in the future. Exploring unknown territory that empowers others and adapts to the needs of a community.\n\n\n\nThere’s no sense in clinging to the personal whims of a clown leading a shit show. Especially when his circus will end up being a $44 billion version of MySpace.", "date_published": "2023-01-15T13:22:56-07:00", "date_modified": "2023-03-22T08:58:48-07:00", "authors": [ { "name": "Craig Hockenberry", "url": "https://furbo.org/author/admin/", "avatar": "https://secure.gravatar.com/avatar/646ce3f178af64df9b0bb9d73e31e3bc?s=512&d=mm&r=g" } ], "author": { "name": "Craig Hockenberry", "url": "https://furbo.org/author/admin/", "avatar": "https://secure.gravatar.com/avatar/646ce3f178af64df9b0bb9d73e31e3bc?s=512&d=mm&r=g" }, "tags": [ "Miscellaneous" ] }, { "id": "https://furbo.org/?p=2600", "url": "https://furbo.org/2022/12/20/simbuddy-your-simulators-bff/", "title": "SimBuddy \u2013 Your Simulator\u2019s BFF", "content_html": "\nHave you ever added code like this to your app?
\n\n\n\nprint(Bundle.main.resourcePath!)\nprint(FileManager.default.urls(for: .documentDirectory, in: .userDomainMask).first!.path)\n\n\n\n
Or maybe you\u2019ve been frustrated that you can’t add that code because you\u2019re in the middle of debugging?
\n\n\n\nYeah, me too. Many times.
\n\n\n\nThe locations shown above, and many others, are available from Xcode using the\u00a0xcrun simctl
\u00a0command. Every application on every device on every platform can be queried. But these lookups are difficult for developers because the information is structured around automatically generated GUIDs. The GUID you\u2019re looking for changes every time a new OS is available, a device is added, or an application is installed. And we do that a lot!
There are other tools available to help you navigate the Simulator, but they all do much more than I really need and take up space in my menu bar even though they are used infrequently. Additionally, none of these tools help find the “On My iPhone/iPad” container used by the Files app: a folder that I use whenever I\u2019m testing import and export code.
\n\n\n\nBy now, you probably know where this is going: yes, I wrote my own utility and call it SimBuddy. It\u2019s a FREE download from the Iconfactory.
\n\n\n\n\n\n\n\nSimBuddy uses two popup menus for navigation: the top one shows which devices are running in the Simulator and the one below shows all the applications installed on that device (your apps are listed first). Once you make a choice with those popups, you can use the buttons at the bottom of the window to navigate in the Finder. If you are using app group containers for sharing information between an extension/widget and your main app, you open those folders by selecting the ID and using “Open”.
\n\n\n\nIf the Terminal is more your thing, you can hold down the option key while clicking a button and a path to the folder is put on the clipboard. Paste that into a command line and away you go!
\n\n\n\nIt\u2019s not a complicated app, as you can see from the source code, but it\u2019s one that I\u2019m very happy to have in my developer toolbox now. I hope you enjoy it, too!
\n\n\n\nP.S. I love putting Easter eggs in apps. This time it\u2019s in the app icon.
\n", "content_text": "Have you ever added code like this to your app?\n\n\n\nprint(Bundle.main.resourcePath!)\nprint(FileManager.default.urls(for: .documentDirectory, in: .userDomainMask).first!.path)\n\n\n\nOr maybe you\u2019ve been frustrated that you can’t add that code because you\u2019re in the middle of debugging?\n\n\n\nYeah, me too. Many times.\n\n\n\nThe locations shown above, and many others, are available from Xcode using the\u00a0xcrun simctl\u00a0command. Every application on every device on every platform can be queried. But these lookups are difficult for developers because the information is structured around automatically generated GUIDs. The GUID you\u2019re looking for changes every time a new OS is available, a device is added, or an application is installed. And we do that a lot!\n\n\n\nThere are other tools available to help you navigate the Simulator, but they all do much more than I really need and take up space in my menu bar even though they are used infrequently. Additionally, none of these tools help find the “On My iPhone/iPad” container used by the Files app: a folder that I use whenever I\u2019m testing import and export code.\n\n\n\nBy now, you probably know where this is going: yes, I wrote my own utility and call it SimBuddy. It\u2019s a FREE download from the Iconfactory.\n\n\n\n\n\n\n\nSimBuddy uses two popup menus for navigation: the top one shows which devices are running in the Simulator and the one below shows all the applications installed on that device (your apps are listed first). Once you make a choice with those popups, you can use the buttons at the bottom of the window to navigate in the Finder. If you are using app group containers for sharing information between an extension/widget and your main app, you open those folders by selecting the ID and using “Open”.\n\n\n\nIf the Terminal is more your thing, you can hold down the option key while clicking a button and a path to the folder is put on the clipboard. Paste that into a command line and away you go!\n\n\n\nIt\u2019s not a complicated app, as you can see from the source code, but it\u2019s one that I\u2019m very happy to have in my developer toolbox now. I hope you enjoy it, too!\n\n\n\nP.S. I love putting Easter eggs in apps. This time it\u2019s in the app icon.", "date_published": "2022-12-20T12:54:15-07:00", "date_modified": "2023-07-09T14:40:58-07:00", "authors": [ { "name": "Craig Hockenberry", "url": "https://furbo.org/author/admin/", "avatar": "https://secure.gravatar.com/avatar/646ce3f178af64df9b0bb9d73e31e3bc?s=512&d=mm&r=g" } ], "author": { "name": "Craig Hockenberry", "url": "https://furbo.org/author/admin/", "avatar": "https://secure.gravatar.com/avatar/646ce3f178af64df9b0bb9d73e31e3bc?s=512&d=mm&r=g" }, "tags": [ "Development" ] }, { "id": "https://furbo.org/?p=2583", "url": "https://furbo.org/2022/11/09/managing-xcode-downloads/", "title": "Managing Xcode Downloads", "content_html": "\nBeginning with Xcode 14, the Simulators for watchOS and tvOS are available as separate downloads (iOS and macOS are still “built-in”). This reduces the app download size significantly, but it also means that you now have to manage these large (3-4 GB) components yourself.
\n\n\n\nWhen you launch Xcode 14 the first time, you are prompted to download additional platforms. Another prompt is displayed when you try to run a target for a platform without a runtime.
\n\n\n\nBut what are these downloads and where are they stored?
\n\n\n\nThe first hint is when you look at Disk Utility. You’ll see a bunch of new “Simulator” volumes mounted under Disk Images:
\n\n\n\n\n\n\n\nWhen you select these volumes, you’ll see that they all mount at /Library/Developer/CoreSimulator/Volumes
. Within each volume you’ll find a legal PDF and a path to a .simruntime
package in a Runtimes
directory. This structure is the same as additional iOS runtimes in /Library/Developer/CoreSimulator/Profile/Runtimes
. These .simruntime
packages contain all the information needed to simulate the device.
Now that you know what Xcode is using, you’ll wonder where it’s getting the disk image. It’s located in a sibling directory: /Library/Developer/CoreSimulator/Images
. That folder also contains an images.plist
file that contains metadata for the disk images. There are only a handful of files there, but on my Mac they use 13 GB of disk space.
And up until a couple of hours ago, that folder contained 7 GB of data that was incompatible with the current version of Xcode. I had to delete these files manually. But how?
\n\n\n\nThe simplest way to manage this space is using the new Platforms panel in Xcode preferences:
\n\n\n\n\n\n\n\nThis window also shows when you last used the runtime: in the screenshot above it’s clear that I can get rid of the iOS 14 and tvOS 16.0 runtimes and save about 25 GB of storage. It’s easy to get those runtimes back if needed, just press the + button. (After downloading a new runtime, it can be used in the Devices & Simulator windows to create a new test device.)
\n\n\n\nIf the command line is more your thing, you can use xcrun
to gather the same information:
$ xcrun simctl runtime list\n\n\n\n
Add a -v
option there if you want more details (from the images.plist
mentioned above). To delete any one of the items listed, use the listed GUID in this command:
$ xcrun simctl runtime delete <GUID>\n\n\n\n
In the end, this short post saved me 32 GB of disk space. If you’re developing for platforms other than the current iOS, you’ll likely see something similar. As time passes, you’ll need to manually keep an eye on this stuff: Xcode can’t clean things up for you because it has no idea what you need.
\n\n\n\nFor additional details, check out Apple’s documentation for installing and managing Simulator runtimes. Thanks go to Jason Yao for helping me figure out a bunch of this stuff!
\n", "content_text": "Beginning with Xcode 14, the Simulators for watchOS and tvOS are available as separate downloads (iOS and macOS are still “built-in”). This reduces the app download size significantly, but it also means that you now have to manage these large (3-4 GB) components yourself.\n\n\n\nWhen you launch Xcode 14 the first time, you are prompted to download additional platforms. Another prompt is displayed when you try to run a target for a platform without a runtime.\n\n\n\nBut what are these downloads and where are they stored?\n\n\n\nThe first hint is when you look at Disk Utility. You’ll see a bunch of new “Simulator” volumes mounted under Disk Images:\n\n\n\nDisk Utility showing four Simulator runtimes.\n\n\n\nWhen you select these volumes, you’ll see that they all mount at /Library/Developer/CoreSimulator/Volumes. Within each volume you’ll find a legal PDF and a path to a .simruntime package in a Runtimes directory. This structure is the same as additional iOS runtimes in /Library/Developer/CoreSimulator/Profile/Runtimes. These .simruntime packages contain all the information needed to simulate the device.\n\n\n\nNow that you know what Xcode is using, you’ll wonder where it’s getting the disk image. It’s located in a sibling directory: /Library/Developer/CoreSimulator/Images. That folder also contains an images.plist file that contains metadata for the disk images. There are only a handful of files there, but on my Mac they use 13 GB of disk space.\n\n\n\nAnd up until a couple of hours ago, that folder contained 7 GB of data that was incompatible with the current version of Xcode. I had to delete these files manually. But how?\n\n\n\nThe simplest way to manage this space is using the new Platforms panel in Xcode preferences:\n\n\n\nXcode settings showing all built-in and downloaded Simulator runtimes.\n\n\n\nThis window also shows when you last used the runtime: in the screenshot above it’s clear that I can get rid of the iOS 14 and tvOS 16.0 runtimes and save about 25 GB of storage. It’s easy to get those runtimes back if needed, just press the + button. (After downloading a new runtime, it can be used in the Devices & Simulator windows to create a new test device.)\n\n\n\nIf the command line is more your thing, you can use xcrun to gather the same information:\n\n\n\n$ xcrun simctl runtime list\n\n\n\nAdd a -v option there if you want more details (from the images.plist mentioned above). To delete any one of the items listed, use the listed GUID in this command:\n\n\n\n$ xcrun simctl runtime delete <GUID>\n\n\n\nIn the end, this short post saved me 32 GB of disk space. If you’re developing for platforms other than the current iOS, you’ll likely see something similar. As time passes, you’ll need to manually keep an eye on this stuff: Xcode can’t clean things up for you because it has no idea what you need.\n\n\n\nFor additional details, check out Apple’s documentation for installing and managing Simulator runtimes. Thanks go to Jason Yao for helping me figure out a bunch of this stuff!", "date_published": "2022-11-09T17:35:35-07:00", "date_modified": "2022-11-09T17:35:35-07:00", "authors": [ { "name": "Craig Hockenberry", "url": "https://furbo.org/author/admin/", "avatar": "https://secure.gravatar.com/avatar/646ce3f178af64df9b0bb9d73e31e3bc?s=512&d=mm&r=g" } ], "author": { "name": "Craig Hockenberry", "url": "https://furbo.org/author/admin/", "avatar": "https://secure.gravatar.com/avatar/646ce3f178af64df9b0bb9d73e31e3bc?s=512&d=mm&r=g" }, "tags": [ "Development" ] }, { "id": "https://furbo.org/?p=2566", "url": "https://furbo.org/2022/09/13/behind-the-app-wallaroo/", "title": "Behind the App: Wallaroo", "content_html": "\nIt’s been awhile since I’ve done one of these deep dives on what goes on behind the scenes during the development of an Iconfactory app. There’s a common thread to each one: I feel the need to document our work when there’s a major change in how we build user interfaces.
\n\n\n\nThe first one was for the “flattening” of Twitterrific 5, a task that preceded Apple’s work in iOS 7 by six months. The next one was for Flare 2, when the Aqua face of macOS began a dramatic evolution in Yosemite.
\n\n\n\nWith Wallaroo, there’s another major change that may not be noticeable on the surface: it’s the Iconfactory’s first app written completely in SwiftUI.
\n\n\n\nIt all started while I was working on Shortcuts support in Tot. During March of this year, I noticed that there was an action to “Set Wallpaper”. I also learned how Shortcuts could be downloaded, installed, and managed using a URLs.
\n\n\n\nThe Iconfactory has been making wallpaper images since the dawn of time, but it never made sense to make an app because changing your wallpaper was a manual task. Shortcuts radically changed this calculus and the idea for an app was born. I threw together a quick prototype that let you set two wallpapers. Sean and I had the beginnings of Wallaroo.
\n\n\n\nOur wallpaper prototype became one of those “we’ll do it some day” projects. Then something important happened: WWDC 2022. After Lock and Home Screen customization was announced, the idea immediately became a “we need to do this before September!” project.
\n\n\n\nWe built Wallaroo from scratch in a little over two months.
\n\n\n\nThe project started with a couple of wrinkles: the “Set Wallpaper” action didn’t work with the new features on iOS 16, so we filed FB10377111 on June 6th (a couple of hours after the keynote ended). We placed our faith in the abilities of the Shortcuts team and decided to carry on in spite of this setback. (We wish everyone at Apple wrote release notes like they do!)
\n\n\n\nThe other wrinkle was that we all had work-in-progress that needed to be finished up. We knew that the short timeframe meant that this was an “all hands on deck” situation, so it wasn’t until the end of June before we all freed up. We put the prototype on TestFlight and got to work.
\n\n\n\nThere were three major areas where we focused our attention:
\n\n\n\nGed, Anthony, Dave, and Talos immediately got to work on the first bullet, but without a backend server, there was no place to put files and metadata. So we made a Numbers spreadsheet and shared it in Dropbox along with the source images. Our Slack channel for the project was filled with “I’m going in” and “I’m out!” to avoid write conflicts. (S.W.A.T. = Software Write Avoidance Technique)
\n\n\n\nI was responsible for the development of the backend. Importing a spreadsheet CSV file gave us our initial database and images in Dropbox let me manually generate thumbnails and other content that would be needed in the app.
\n\n\n\nSean took the lead on the app. We’ve been holding back on SwiftUI due to its immaturity, but the changes in iOS 16 looked great, so we went all in (the only UIKit/AppKit code is in delegate connectors). The data in the spreadsheet was massaged again to give him some real data to use.
\n\n\n\nTalos took the lead on the app architecture and the wireframe was finished on July 5th. A week later we had enough working code to make a Git repository. A few days later Sean showed us his Captain Pike Appreciation App:
\n\n\n\n\n\n\n\nWe were on our way, but had less than two months before an iPhone announcement. Time to kick butt.
\n\n\n\nJuly was a blur. Progress was quick and everyone was heads down on their app responsibilities.
\n\n\n\nRemember that bug in Shortcuts that prevented Set Wallpaper from working in iOS 16? It was still around and we were starting to get worried. When iOS 16 beta 5 dropped on August 8th, we rejoiced when our test ran. The shortcut action worked perfectly!
\n\n\n\nOur last update to the shared spreadsheet was on August 10th. From that point on, we were able to use our new content management system to add and update wallpaper. There was still a ton of work needed to clean up metadata and fine tune each wallpaper release.
\n\n\n\nWith the new server up and running, we started testing push notifications. Since Sean’s focus was still in the primary user interface, I started working on the SwiftUI views and models that talked to our backend server. That work continued with integrating the Patreon API and hooking up StoreKit2 for subscriptions. I also had a blast doing the User License and Credits screens.
\n\n\n\nWe started our first beta test with Patreon supporters on August 25th. We were going to make the mid-September release date!
\n\n\n\nLooking back on the development, I think there were two things working in our favor: experience and SwiftUI.
\n\n\n\nWe’ve made a lot of apps and have an instinctual knowledge on how to build them. But no matter how little friction there is in working together, you still have to put the pieces together.
\n\n\n\nSwiftUI is incredibly good at doing that.
\n\n\n\nKeep in mind that neither Sean or I had created a full-fledged app using SwiftUI (widgets don’t count). We had to learn the idioms and best practices, but once that was overcome, development happened at a lightning pace.
\n\n\n\nWe encountered roadblocks, of course. Tracking down memory leaks was harder than UIKit because of the abstractions. Figuring out how to share an image was a huge head scratcher. Implementing parallax in a ScrollView was many days of hard work. And you should see the comments in our PagingView!
\n\n\n\nBut overall, the experience was extremely positive. If you’ve been on the fence with this technology, iOS 16 feels like a turning point in SwiftUI’s evolution.
\n\n\n\nNow that you’ve read about how we made it, take Wallaroo for a spin. It’s a FREE download and a fun little app for iOS 16. And a great example of what you can do with SwiftUI.
\n", "content_text": "It’s been awhile since I’ve done one of these deep dives on what goes on behind the scenes during the development of an Iconfactory app. There’s a common thread to each one: I feel the need to document our work when there’s a major change in how we build user interfaces.\n\n\n\nThe first one was for the “flattening” of Twitterrific 5, a task that preceded Apple’s work in iOS 7 by six months. The next one was for Flare 2, when the Aqua face of macOS began a dramatic evolution in Yosemite.\n\n\n\nWith Wallaroo, there’s another major change that may not be noticeable on the surface: it’s the Iconfactory’s first app written completely in SwiftUI.\n\n\n\nA Discovery\n\n\n\nIt all started while I was working on Shortcuts support in Tot. During March of this year, I noticed that there was an action to “Set Wallpaper”. I also learned how Shortcuts could be downloaded, installed, and managed using a URLs.\n\n\n\nThe Iconfactory has been making wallpaper images since the dawn of time, but it never made sense to make an app because changing your wallpaper was a manual task. Shortcuts radically changed this calculus and the idea for an app was born. I threw together a quick prototype that let you set two wallpapers. Sean and I had the beginnings of Wallaroo.\n\n\n\nOur wallpaper prototype became one of those “we’ll do it some day” projects. Then something important happened: WWDC 2022. After Lock and Home Screen customization was announced, the idea immediately became a “we need to do this before September!” project.\n\n\n\nTime is Tight\n\n\n\nWe built Wallaroo from scratch in a little over two months.\n\n\n\nThe project started with a couple of wrinkles: the “Set Wallpaper” action didn’t work with the new features on iOS 16, so we filed FB10377111 on June 6th (a couple of hours after the keynote ended). We placed our faith in the abilities of the Shortcuts team and decided to carry on in spite of this setback. (We wish everyone at Apple wrote release notes like they do!) \n\n\n\nThe other wrinkle was that we all had work-in-progress that needed to be finished up. We knew that the short timeframe meant that this was an “all hands on deck” situation, so it wasn’t until the end of June before we all freed up. We put the prototype on TestFlight and got to work.\n\n\n\nDivide and Conquer\n\n\n\nThere were three major areas where we focused our attention:\n\n\n\nContent – Hundreds of wallpapers had been created over the years, but resolution and aspect ratio varied widely. Things needed to be cleaned up.Backend – Over years, we had done releases in an ad-hoc manner: uploading ZIP files to a Patreon account would no longer be acceptable. We needed a server to manage the wallpapers. Frontend – An app to display the wallpapers: it had to look and work great. Sexy and fast were primary design goals.\n\n\n\nGed, Anthony, Dave, and Talos immediately got to work on the first bullet, but without a backend server, there was no place to put files and metadata. So we made a Numbers spreadsheet and shared it in Dropbox along with the source images. Our Slack channel for the project was filled with “I’m going in” and “I’m out!” to avoid write conflicts. (S.W.A.T. = Software Write Avoidance Technique)\n\n\n\nI was responsible for the development of the backend. Importing a spreadsheet CSV file gave us our initial database and images in Dropbox let me manually generate thumbnails and other content that would be needed in the app.\n\n\n\nSean took the lead on the app. We’ve been holding back on SwiftUI due to its immaturity, but the changes in iOS 16 looked great, so we went all in (the only UIKit/AppKit code is in delegate connectors). The data in the spreadsheet was massaged again to give him some real data to use.\n\n\n\nTalos took the lead on the app architecture and the wireframe was finished on July 5th. A week later we had enough working code to make a Git repository. A few days later Sean showed us his Captain Pike Appreciation App:\n\n\n\n\n\n\n\nWe were on our way, but had less than two months before an iPhone announcement. Time to kick butt.\n\n\n\nButt Kicking\n\n\n\nJuly was a blur. Progress was quick and everyone was heads down on their app responsibilities.\n\n\n\nRemember that bug in Shortcuts that prevented Set Wallpaper from working in iOS 16? It was still around and we were starting to get worried. When iOS 16 beta 5 dropped on August 8th, we rejoiced when our test ran. The shortcut action worked perfectly!\n\n\n\nOur last update to the shared spreadsheet was on August 10th. From that point on, we were able to use our new content management system to add and update wallpaper. There was still a ton of work needed to clean up metadata and fine tune each wallpaper release.\n\n\n\nWith the new server up and running, we started testing push notifications. Since Sean’s focus was still in the primary user interface, I started working on the SwiftUI views and models that talked to our backend server. That work continued with integrating the Patreon API and hooking up StoreKit2 for subscriptions. I also had a blast doing the User License and Credits screens.\n\n\n\nWe started our first beta test with Patreon supporters on August 25th. We were going to make the mid-September release date!\n\n\n\nSwiftUI FTW\n\n\n\nLooking back on the development, I think there were two things working in our favor: experience and SwiftUI.\n\n\n\nWe’ve made a lot of apps and have an instinctual knowledge on how to build them. But no matter how little friction there is in working together, you still have to put the pieces together.\n\n\n\nSwiftUI is incredibly good at doing that.\n\n\n\nKeep in mind that neither Sean or I had created a full-fledged app using SwiftUI (widgets don’t count). We had to learn the idioms and best practices, but once that was overcome, development happened at a lightning pace.\n\n\n\nWe encountered roadblocks, of course. Tracking down memory leaks was harder than UIKit because of the abstractions. Figuring out how to share an image was a huge head scratcher. Implementing parallax in a ScrollView was many days of hard work. And you should see the comments in our PagingView!\n\n\n\nBut overall, the experience was extremely positive. If you’ve been on the fence with this technology, iOS 16 feels like a turning point in SwiftUI’s evolution.\n\n\n\nGive It a Go!\n\n\n\nNow that you’ve read about how we made it, take Wallaroo for a spin. It’s a FREE download and a fun little app for iOS 16. And a great example of what you can do with SwiftUI.", "date_published": "2022-09-13T11:49:34-07:00", "date_modified": "2022-09-13T11:49:34-07:00", "authors": [ { "name": "Craig Hockenberry", "url": "https://furbo.org/author/admin/", "avatar": "https://secure.gravatar.com/avatar/646ce3f178af64df9b0bb9d73e31e3bc?s=512&d=mm&r=g" } ], "author": { "name": "Craig Hockenberry", "url": "https://furbo.org/author/admin/", "avatar": "https://secure.gravatar.com/avatar/646ce3f178af64df9b0bb9d73e31e3bc?s=512&d=mm&r=g" }, "tags": [ "Development" ], "attachments": [ { "url": "https://furbo.org/stuff/Captain-Pike-Appreciation-App.mp4", "mime_type": "video/mp4", "size_in_bytes": 1494887 } ] }, { "id": "https://furbo.org/?p=2563", "url": "https://furbo.org/2022/06/03/lame-until-it-isnt/", "title": "Lame, Until it Isn\u2019t", "content_html": "\nWhere there\u2019s smoke, there\u2019s fire. And as we approach WWDC 2022, there\u2019s a lot of smoke around AR and VR. In some ways, this is going to be a huge inflection point, in other ways, it\u2019s probably going to be a letdown.
\n\n\n\nRemember when the iPod was announced? Some folks called it lame because it didn\u2019t meet their expectations.
\n\n\n\nThe same thing will be true of anything Apple wants us to put on our face. It\u2019s going to less impressive technically than any of the currently shipping products. And that\u2019s good, because you don\u2019t make fundamental changes by tweaking existing technologies. A Nomad audio player was a tweak. An Oculus headset is a tweak.
\n\n\n\nEverything we\u2019ve seen to date with VR has been an attempt to bring information to a 3D world. Headsets are just a means to project that 3D environment so our eyes can see it.
\n\n\n\nI think Apple\u2019s approach with AR will be completely different: they will bring 3D to an information world.
\n\n\n\nWe all have the greatest source of information humankind has ever known in our pocket or purse. Much of that information relates to the world around us: weather, transportation, shopping, dining, etc. Relating that data to our physical space will be a powerful tool.
\n\n\n\nAll the AR examples we\u2019ve seen on Apple\u2019s devices hint at this direction. They take the information on our phone and place it at derived 3D coordinates. Where people get tripped up in these demos is where the results are shown: on a standard screen.
\n\n\n\nI don\u2019t think that\u2019s Apple\u2019s final goal, because any current screen technology will block your view of the real world. It\u2019s also why I think 3D headsets will remain a niche technology: people have innate need to see what\u2019s going on around them.
\n\n\n\nOur current screens also use a lot of power. And that means batteries. And that means weight. Not what I want on my face, for sure.
\n\n\n\nApple knows this and that\u2019s why I think a new display system is the thing they\u2019re taking time to get right. We may or may not see this new display at WWDC. I can remember a time when all we had for an iPad was a simulator.
\n\n\n\nThe changes caused by a new display will be incremental. There will certainly be technical limitations in the product that are imposed by size and weight: Apple will improve on those things as components allow.
\n\n\n\nOther changes will happen because no one, including Apple, really knows how this display will be used by normal folks (we, I should note, are not normal folks). The first Apple Watch tried to do a lot of things: iteration got rid of things no one used, and improved the things everyone wanted.
\n\n\n\nIt\u2019s likely that a first iteration will also be a \u201csatellite device\u201d where the iPhone does the heavy lifting. Much like the original iPod relied on a Mac. The realityOS could be nothing more than widgets for a new display on your face.
\n\n\n\nThat will feel lame until you realize something else: after two decades, the basic form factor and functionality of that first iPod is now an essential part of our lives and we call it an iPhone. Don\u2019t underestimate Apple\u2019s ability to iterate.
\n", "content_text": "Where there\u2019s smoke, there\u2019s fire. And as we approach WWDC 2022, there\u2019s a lot of smoke around AR and VR. In some ways, this is going to be a huge inflection point, in other ways, it\u2019s probably going to be a letdown.\n\n\n\nRemember when the iPod was announced? Some folks called it lame because it didn\u2019t meet their expectations.\n\n\n\nThe same thing will be true of anything Apple wants us to put on our face. It\u2019s going to less impressive technically than any of the currently shipping products. And that\u2019s good, because you don\u2019t make fundamental changes by tweaking existing technologies. A Nomad audio player was a tweak. An Oculus headset is a tweak.\n\n\n\nEverything we\u2019ve seen to date with VR has been an attempt to bring information to a 3D world. Headsets are just a means to project that 3D environment so our eyes can see it.\n\n\n\nI think Apple\u2019s approach with AR will be completely different: they will bring 3D to an information world.\n\n\n\nWe all have the greatest source of information humankind has ever known in our pocket or purse. Much of that information relates to the world around us: weather, transportation, shopping, dining, etc. Relating that data to our physical space will be a powerful tool.\n\n\n\nAll the AR examples we\u2019ve seen on Apple\u2019s devices hint at this direction. They take the information on our phone and place it at derived 3D coordinates. Where people get tripped up in these demos is where the results are shown: on a standard screen.\n\n\n\nI don\u2019t think that\u2019s Apple\u2019s final goal, because any current screen technology will block your view of the real world. It\u2019s also why I think 3D headsets will remain a niche technology: people have innate need to see what\u2019s going on around them.\n\n\n\nOur current screens also use a lot of power. And that means batteries. And that means weight. Not what I want on my face, for sure.\n\n\n\nApple knows this and that\u2019s why I think a new display system is the thing they\u2019re taking time to get right. We may or may not see this new display at WWDC. I can remember a time when all we had for an iPad was a simulator.\n\n\n\nThe changes caused by a new display will be incremental. There will certainly be technical limitations in the product that are imposed by size and weight: Apple will improve on those things as components allow.\n\n\n\nOther changes will happen because no one, including Apple, really knows how this display will be used by normal folks (we, I should note, are not normal folks). The first Apple Watch tried to do a lot of things: iteration got rid of things no one used, and improved the things everyone wanted.\n\n\n\nIt\u2019s likely that a first iteration will also be a \u201csatellite device\u201d where the iPhone does the heavy lifting. Much like the original iPod relied on a Mac. The realityOS could be nothing more than widgets for a new display on your face.\n\n\n\nThat will feel lame until you realize something else: after two decades, the basic form factor and functionality of that first iPod is now an essential part of our lives and we call it an iPhone. Don\u2019t underestimate Apple\u2019s ability to iterate.", "date_published": "2022-06-03T10:21:43-07:00", "date_modified": "2022-06-03T10:21:43-07:00", "authors": [ { "name": "Craig Hockenberry", "url": "https://furbo.org/author/admin/", "avatar": "https://secure.gravatar.com/avatar/646ce3f178af64df9b0bb9d73e31e3bc?s=512&d=mm&r=g" } ], "author": { "name": "Craig Hockenberry", "url": "https://furbo.org/author/admin/", "avatar": "https://secure.gravatar.com/avatar/646ce3f178af64df9b0bb9d73e31e3bc?s=512&d=mm&r=g" }, "tags": [ "Design", "Development", "Observation", "Opinion" ] } ] }