[Saadia] Writing vs Publishing

Another Johnny Decimal update. MVP, STE, or just DIY? Questions on writing.

An async podcast by Saadia Carbis and Joshua Wold.

Chapters

• 0:00 Intro … ?
• 2:00 Johnny Decimal Update
• 9:27 Red line design
• 10:18 Design processes
• 17:53 Testing
• 18:39 Writing vs Publishing

Transcript

0:01

Hello, welcome to Async. This is Saadia and Async is a back and forth conversation between myself and Joshua about design systems, about writing and about making apps and working remotely, that sort of thing. I would have a preset introduction, but Joshua has challenged me and I've taken up the gauntlet to try to improvise an introduction and make it different each time. Listeners, will you get in touch, please? Our contact details are available at async.fm and I want you to let us know, is it better to wing it each time? Maybe it's becoming an in-joke or perhaps it's better to have a preset introduction. I know for me, I really like preset introductions on podcasts. So usually these podcasts, not usually always, these podcasts, they're a conversation format. So I'm addressing you now, Joshua. Joshua, how are you doing, mate? There's this one podcast I used to listen to all the time back when I was really heavy into VR. It was called The Voices of VR Podcast with Kent Bai. And I can still remember the introduction word for word, you know. And another good example of this is ATP Accidental Tech Podcast. I could sing you the little outro jingle that they've got word for word, including spelling out their social media handles. So, you know, I think there's something to be said for a preset podcast intro, but maybe our listeners will let us know. Maybe I'm wrong and I'm not really that attached to either way. You can keep doing whatever you want. All right. Follow up. Johnny Decimal System, man, your suggestions were brilliant. So I've been having, I've been implementing the Johnny Decimal System on my machine, on my work machine. And basically what this means is you can read more about it at johnnydecimal.com. And it means that you're setting up folders with a numbering system to make it easy to keep track of all of the different projects and life things happening in all the different domains of your life. It's a nice way of organizing files, notes, emails, although like you, I tend to be inbox zero. And so that doesn't so much apply. And keep everything neatly organized across a range of different apps. And this system has been great for me, except for the downside of having to open up folders and nested folders is an issue with the system. Folders inside folders, inside folders, inside folders. So there's been another issue with the system, actually, which is that as a result of this, I used to keep all of my Git repos in the sites folder of my... You know you've got your home folder on your Mac? And then there's a sites folder. At least there used to be. I think in modern versions of Mac OS that doesn't exist by default. But if you create a sites folder, then it will get the icon that it's supposed to have. And I always kept my Git repos in there. Because in the early days, there were always websites. And as times have changed, I've started adding Xcode projects there and various other bits and bobs, games that I'm working on. So long as it's Git, it can go in sites. And that doesn't really make sense. And it doesn't make sense in a Johnny Decimal system either. So I started moving all my Git repos into my documents folder. And that's caused a problem. Because now I've got all these Node modules files, all these Node modules folders, with all these tiny, tiny dependency files. And it's gigabytes and gigabytes syncing to iCloud that doesn't need to be synced to iCloud. It's so thousands upon thousands of files. And they're all in Git. And they're all on NPM. I don't need them. So I've had to figure out how to do that. And I don't know if you're aware. But if you rename a folder and put the extension .nosync, N-O-S-Y-N-C, at the end of the folder name, it won't sync to iCloud. So then I've got all of these folders that are labeled, I don't know, 20.01, plugin. And that's kind of ugly. So instead of doing that, what I've then done is, I mean, maybe this is a blog post. I've then gone and hidden the folders, which you can also do by putting a... So what I've done is I've got these nosync folders. Then I've created an alias to the folder. I can call the alias whatever I want. And then hidden the original folder. Anyway, it's a whole ordeal. So that's been another sort of problem with the Johnny Decimal system and using it with iCloud specifically. I'd say it's more of an iCloud problem than a Johnny Decimal problem. But it's one I've been able to overcome. And in the process, I used to have in my sidebar, I don't know if you remember this, but back in the early days of macOS, in the sidebar of Finder, there used to be a home folder. And that, at one point, changed to your username instead of the word home. And that annoys me because my username starts with a lowercase letter, as all usernames should. And everything else in my sidebar has an uppercase. You know, applications, uppercase. Airdrop, uppercase. So that really, really bothered me. So what I've done is, inspired by all of this extra work I had to do, is I created an alias to my, you know, Saadia folder on my computer, renamed the alias to home, and put that in my sidebar. And that works really nicely. And then I can just hide the alias itself, and I never see it. By the way, I didn't realize until recently, but there is a great shortcut. Command, shift, period. And that hides and shows all of the hidden files in Finder. Okay. Where was I going with this? I just saw I've been just messing around in Finder. So then you suggested having a recents folder for the Johnny Decimal System. Fantastic. Why didn't I think of that? So I did. I created a smart folder, which is a Finder feature. And I set it up with some, how do you say, a particular search term. And I set it up so it's only showing me folders, only showing me folders that have like number, number, period, number, number. And so that way, I'm not actually seeing all of the recent files, or even all of the recent folders. I'm only seeing specific project folders in that recent. And of course, only if they were open in the last seven days. And that has been a real, it's solved the problem, essentially. Solved the problem I was having with all of the nested things. I don't mind a little nesting when it's something I haven't accessed in a while. But this recents folder is a real shortcut to the specific project folders that I've been working on actively. It's made me really, really happy with the Johnny Decimal System, actually, because of this. Except that a smart folder in Finder isn't actually a folder. It's actually a file. I think it's a .smart folder extension..smart folder, one word, I think is what it is. And then Finder sort of, you know, uses that file. So because it's a file, you can't add it to your sidebar. You can't put it in your sidebar. And I really wanted it in my sidebar. So once again, I turned to my alias system and I created an alias for it. Managed to get the alias in the sidebar. Oh, hurrah. Okay. So I've got things working really nicely now. Only gripe is that I wish I could have Finder open up its default window to be the recents folder. Does that make sense? I want it to open by default to recents. Anyway. I can't figure that bit out. But aside from that, everything's working nicely. Okay. Next topic. Red marker method. That's what I wrote down in my notes. And that's what I originally wanted you to call it. Because I feel for me in my mind, it is a evolution of the fat marker sketch. It's like a extension of that system. You've got the fat marker sketch. And then you have the red marker method. I like method because I don't like system. I don't know something about system. And this is important. We're talking about a chapter title here. But then you texted me and you suggested red line design. So the red line design method. I like that. The internal rhyme with line and design. I don't know if this is a chapter or an entire book. But I definitely think it's worth writing more about. You asked me in the previous episode, how do I go about building and designing apps? Specifically like the design process. I had coffee with a friend of mine yesterday, Brendan. And he is a product manager on an R&D team. So he's got all the experience with this sort of thing, right? And they're out there building a bunch of different apps at the moment. Except they're not apps. And they're not even MVPs. He talked about how they're creating STEs. Smallest Testable Experience. That's some jargon that I've come across before. To test out whether something is viable. We're talking about whether AI tools like Cursor are good for building smallest testable experiences. That's another topic entirely. I don't want to talk to it because I'm not sure how I feel about it yet. But I realized talking to him about MVPs and STEs. That there's a part of me that really hates these concepts. I'm pushing back against it. I feel like a real friction. A real distaste for MVP, STE, this sort of thing. Maybe it's like the pirate blood in me that doesn't want to conform to whatever the norms are within the industry. But I mean, I'm sure that that's what it is. But I don't know. Sometimes, don't you think you just have to back yourself? You know, sometimes you've just got to go, You know what? I'm a designer. I think this looks good. I think this works well. I think it's easy to use. I'm going to keep iterating on it. I'm not going to bother testing it. I'm not going to go to people and ask them their opinion. Actually, wasn't there a Daring Fible article just this week talking about how when Aqua came out, there was a feedback table at Macworld when 10.0 or 10.1, no, 10.0 introduced the new Aqua design language. And there was all of these developers who were so upset with how it worked. And they thought it was hard to use. It was unnecessarily graphic. And after that, Apple stopped taking feedback from developers. I think sometimes we have to do the same thing. We have to stop taking feedback from stakeholders. We have to stop taking feedback from users and customers. And just really back ourselves, you know. And that goes for design, as in visual design. But I think it also goes for product design, user experience design. So how do I build and design apps? I don't use design systems. As we've talked about on previous shows, rely heavily, heavily on two things, really. I mean, if I'm going to write the book, then I'm going to say I rely heavily on two things. One is the native controls. The native components. The native UI system. Not building my own components from scratch. Often, you'll pick up an app and you'll go, oh, this app, like Spotify, for example. This app looks different from the entire rest of the operating system. And they've got a design language. They've got a design system. And in this case, because Spotify has a web app, it's got an Android app, and it's got an iOS app. They've made the decision. We want our app experience to be the same however you come across it. We always want it to be basically the same thing. So we've got our own design system. Well, I say, no, that's rubbish. Don't do it that way. Better way, lean into the native controls for the operating system you're working on. Lean into the native Mac controls, which are different than native iOS. Lean into the, if you're building an Android app, build a native Android app. Use the native controls on Android. Do you know what I mean? So really, there's a lot of benefits to that. One is that it looks like it fits on the device. And that's really nice. Two is that you'll encounter far less bugs. Three is that updates to the design system will happen, and they will apply automatically without you needing to do very much. Three is that you don't need to develop, I mean, where am I up to? Three, four? You don't need to develop the components yourself. They already exist. So there's a bunch of benefits to doing it this way. And I think that that's how people should, I mean, that's my recommendation. Especially, especially for a startup. Especially for a new product. And of course, especially if you don't plan to bring your product to Android, at least in the short term, then it's a lot less work. Just build it for iOS. And use Swift UI, Swift native controls, Swift native components. Then the second, that's the first bit of advice. The second bit of advice is something you actually talked about in the last episode too, is look at what other people are doing. Go and find other apps. And you talked about apps in different verticals. Not in your vertical, but in different verticals. That makes a lot of sense. I really like that approach. But I have a slightly different spin on it. Which is, I look for apps that have the same information architecture as you. It doesn't matter what vertical they're in. It doesn't matter whether they're in the same or if they're different verticals. So long as you put yourself on do not disturb mode. And so you don't get interrupting text messages during your podcast. And so long as they have the same basic structure to their app. Because when they've got that, then you can see, oh, they've got the navigation in this particular location. That works or it doesn't work. Or I like the way that this app has done the sort of sub item from the list. How they've got the item. Maybe it makes sense for the item to come into a new screen. Or maybe it only makes sense for it to be a modal pop-up at the bottom of the screen. And I would, so I try to gather as many apps with the same information architecture. Or similar information architecture that I like the look of. And I just spend time just pouring through those. Days and days. Pouring through those. I'll take screenshots, especially of the ones I like. Take some notes. And then I'll just start copying them. Often it's an amalgam of different apps. And I end up with a bit of a mishmash of design approaches. But it almost always works. And when it doesn't, that's okay. Because I can just keep editing and changing. Of course, I don't design beforehand. I design in code. And that's not something that's suited to everyone. But it makes it easy to test. All right. And then we have testing. Maybe this is a new topic. Testing. Two things on testing. The first thing is you've got to test on device. All right. It's no good testing in the simulator. You've got to get the app onto an iPhone in order to test the iPhone app. If you're doing a Mac app, test it on Mac. If you're doing an Android app, test it on Android. On-screen simulators are useless. Especially when the interface is a touch interface. And you're using a keyboard and mouse or trackpad. So that's the first thing for testing. And I've forgotten the second thing. If I remember it, I'll tell you it next time. All right. Last topic for today. Writing versus publishing. I committed in November, December to, you know, I've started this new blog. And I committed to writing regularly on the blog. Not every day. But, you know, most days. This week, I've only published one time. And it's the lightest blog week I've ever had. Now, I really, really believe that writing is so, so important. And that everybody should write. If you're a listener and you don't already write. Maybe a journal suits you well. But maybe consider blogging. It does so much to consolidate ideas inside your head. It locks in knowledge and understanding. All right. I won't go into, like, the taxonomies of learning here. But it's really, really helpful practice. Everybody knows it, really. I think, deep down inside. And we've all heard this advice hundreds of times before. So, here's your, you know, 39th reminder this year to start writing stuff down if you don't already. I think it's really important. But my question is, the difference between writing and publishing. I've done lots of writing this week. I've done lots of writing this week. But I've only published once. What do you think? How important is it to publish versus write? What if you're writing a private journal? Do you get the same benefits? Do you get different benefits? I've been writing a Dungeons & Dragons homebrew handbook full of poetry, full of inventions. And it's been, I've had an absolute blast with it. I've also been writing, like, a bunch of, like, reflections on academic literature that I've been reading. But, you know, I haven't published any of that. Maybe I'll just publish some of my notes and quickly format them. The question is, if I've already got these notes, right? I've already read these articles, written up some notes and thoughts on them. I've gotten the benefit from that. Will I get very much further benefit from publishing them? You know, there's going to be some cost to it. I've got to spend, it'll probably take me 20 to 30 minutes to take my notes, move them into a format that will make it easy to read and publish them onto my blog. Is that extra benefit, having already written it, is the extra benefit in actually publishing it worthwhile? while.