RVS_Spinner VS RVS_BlueThoth

I learned the hard way, that iconic UI is probably not the best way to go.

But designers pretty much insist on it, these days, and fun, ensues (and sometimes, FukN sues).

I have found the best UI, is UI that gets out of the way, and doesn't call attention to itself. There's a reason that waitstaff usually wear black.

An example: I designed this really clever Swift UI widget (not SwiftUI)[0].

I keep trying to use it in my projects, and keep removing it, because it's too "in your face."

[0] https://github.com/RiftValleySoftware/RVS_Spinner

I generally have a “What Problem Does This Solve?” section in my READMEs.

https://github.com/LittleGreenViper/LGV_TZ_Lookup#what-probl...

https://github.com/LittleGreenViper/LGV_MeetingServer#what-p...

https://github.com/RiftValleySoftware/RVS_Spinner#what-probl...

https://github.com/RiftValleySoftware/RVS_BlueThoth#what-pro...

https://github.com/RiftValleySoftware/RVS_PersistentPrefs#wh...

etc.

I have had quite a bit of experience with this.

I'm primarily a native Apple application developer, but have done some backend stuff, as well. I have designed numerous Web sites, but I am not a particularly skilled Web designer.

I was, in the days of yore, an artist. I have also taken numerous design and usability course, from the likes of NNG (Nielsen-Norman Group).

I have designed a bunch of fancy widgets[0 - 4]. I actually use very few of them, because they are too intrusive.

I am in the "refining UX" stage of an iOS app that I've been developing for the last year and a half, or so. I'm working with designers and testers, to clean up the information architecture, interaction, usability, aesthetic design, and accessibility.

For me, the most valuable technique, has been rapid, high-quality prototyping. I have been abusing Apple's TestFlight[5] beta release system, and have been using it to make regular (usually, a couple a day) releases to the rest of the team, who are mostly non-tech people. I've made over 600 releases. The first release was made less than a month after first code submission.

The way I use it, is that I run what I call "constant beta." The app is always at "ship" Quality, even if incomplete. This means that the code people get, is fully operational, for the currently developed feature set.

This has the advantage of constant vetting by Apple. They don't test TestFlight to the same level as the App Store, but they look for things like unsupported API usage, code signing issues, and obvious quality issues (like crashes). In at least one case, their testing found a crash that I missed.

Once the first release for a version has been vetted (takes a day or so), subsequent build releases, within that version are approved almost immediately, so I get quick turnaround.

If the testers encounter crashes, I get a fairly useless report. If I use a Ouija board, I can often figure out the general part of the application affected.

With this workflow, we can have a highly iterative process, with aesthetics, usability, and general UX, being tested, almost from the start.

I'm pretty good at interpreting designs. I can accept Figma, Photoshop, Sketch, Illustrator, Napkin Sketch, or Hand-Wavy Verbal Description, and turn it into UX. I usually have something for the designers to try out, within minutes.

Most of the actual code assets are generated via Illustrator, and I will often redesign raster art, into vector.

The designers and non-tech stakeholders seem to like it.

WFM. YMMV.

[0] https://github.com/RiftValleySoftware/RVS_Spinner

[1] https://github.com/RiftValleySoftware/RVS_MaskButton

[2] https://github.com/RiftValleySoftware/RVS_Checkbox

[3] https://github.com/RiftValleySoftware/RVS_RetroLEDDisplay

[4] https://github.com/RiftValleySoftware/RVS_AutofillTextField

[5] https://developer.apple.com/testflight/

He's talking about this spinner apparently https://github.com/RiftValleySoftware/RVS_Spinner

I've become unenamored of the "Measured Human" lifestyle.

This is where everything we do is metered, and our lives become "data-driven."

It does bring results, but I feel there are significant costs; usually difficult to measure.

One of the things that I will do, as I write software, is evaluate the code I'm working on, for reusability.

Often, to make something reusable, I need to avoid optimizing it for a specific application, and "generalize" it.

Most of my little SPM modules were developed this way. If I think it deserves it, I'll stop work on my principal project, and break out the subsystem into its own project and repo. Once I have it standalone, tested, and ready, I will re-integrate it, as an external SPM module.

In more than one instance, I have removed the code from the principal project, because it was not something that would contribute to the main goal.

But I now have this neat little SPM module, ready to be used in other projects. Here's an example of a project that never made it into any of final results, but I think is pretty neat[0].

Some of my modules are basically my "baseline." These are used in everything I do.

Many would consider my workstyle "wasteful," but it works for me.

[0] https://github.com/RiftValleySoftware/RVS_Spinner

It's an interesting article, and I appreciate the readability (good formatting, images, etc.).

Personally, I am absolutely against any kind of debt. It has served me well, but has also given me a personally humble lifestyle. I also worked for a 100-year-old Japanese corporation that was (and still is) ferociously debt-averse. Personally, I feel that my debt-aversion has been a great asset. I'm not so sure that debt-aversion was as good for the corporation I worked for.

But then, "good" is relative. They are 100 years old. That's pretty badass. They got to be 100 by being risk-averse, and building on a robust foundation. But they are also relatively small. Their aversion to debt meant that competitors passed them by, in Ferraris, while they were chugging along in their trusty Volvo.

Often passing flaming, expensive wrecks...

But I digress. It also made it a huge pain to develop software for these folks. I feel as if there was so much design (that yellow curve), that the software suitability suffered.

I consider tech debt to be anything that we say "We'll deal with that down the road." It's really that simple. It may be high issue counts, inflexible design, usability issues, resource usage, cost to maintain, etc.

The word "debt" has a lot of shame attached to it. When I first got married, we needed to use a significant portion of our wedding presents to pay off the credit card debt that I brought into the relationship. That was something that caused me great shame, and was a principal motivator for my "live humble and debt-free" philosophy, thereafter. I have never carried a balance on credit cards, since. So I have a ridiculously high credit score, but I probably would have a hard time actually borrowing money (so I'm told. I haven't actually tried -the mortgage for my house, and leasing cars has never been an issue).

"Tech debt," as the author states, is also often assumed to be the result of "poor code." There's a lot of really badly-written code out there, but much of it is relatively debt-free, due to being tested, encapsulated, and well-maintained. It wasn't allowed past the velvet rope, until it had cleaned up its act.

I've also shitcanned dependencies that had well-written code, unit tests, eye-candy Web sites, and great presentation, but suffered serious bugs.

Usability and localization are the things that have resulted in a couple of bent-nose guys telling me how it would be a shame if anything would happen to my kneecaps. Usability, in particular, is a killer. I have designed, implemented, then removed, some pretty fancy widgets, because they proved to be nice on paper, but unsuitable to my needs in practice. An example is my RVS_Spinner widget[0]. My RVS_Checkbox widget[1], on the other hand, has proven to be marvelously useful.

When it comes to usability, in my experience, there's absolutely no substitute for actually putting the code out there, and letting people play with it. Early beta-testing is crucial, and I have found that it's also important that the code be full ship-quality; not lash-up-test quality. That's because, if Management likes the demo, it becomes ship code; whether or not I want it to be so. It also means that, if rejected, I toss out ship-quality code. Sometimes, I may keep the code, and polish it up for future use (that's one reason that I have so many small module packages out there).

Localization and security, in my experience, are things that are easy to manage, if baked in from the start, and a fang-toothed nightmare, if added after the fact. So not dealing with those from the start, is an example of "I'll deal with that down the road," that I can live to regret.

Since leaving my last employer, I have been experimenting with what I term "ultra-agile" development techniques. I despise tech debt, so I am trying to figure out how to get "the best of both worlds." The results, so far, have been promising, but my scale is, by necessity, fairly small.

But that's just my experience. YMMV.

[0] https://github.com/RiftValleySoftware/RVS_Spinner

[1] https://github.com/RiftValleySoftware/RVS_Checkbox

I generally have a “What Problem Does This Solve?” section in my READMEs.

https://github.com/LittleGreenViper/LGV_TZ_Lookup#what-probl...

https://github.com/LittleGreenViper/LGV_MeetingServer#what-p...

https://github.com/RiftValleySoftware/RVS_Spinner#what-probl...

https://github.com/RiftValleySoftware/RVS_BlueThoth#what-pro...

https://github.com/RiftValleySoftware/RVS_PersistentPrefs#wh...

etc.

> I had one developer take 6 months to build a (relatively simple) top nav for a web app. This shouldn't have taken more than 1-2 weeks, even with a careful eye for detail.

Oh, you mean "bikeshedding."

Here's an example of the difference between basic quality, and High Quality:

If you look at most of the repos for SPM modules in my portfolio[0], you'll see that the vast majority have test harnesses. I prefer using test harnesses[1].

These test harnesses tend to be pretty damn robust apps. Many are "ready for app store" robust. A lot of folks would just publish them, "as is." I've been writing apps for a very long time. I'm fairly good at this.

I can write a fairly good test harness, with full app capabilities, in less than a day. If I take the time to localize it, maybe add a day or so.

Here's an example of some test harnesses[2]. Note that there are four of them. These represent the four different target environments for Apple (iOS/iPadOS, WatchOS, TVOS, and MacOS). I'll probably need to fork iOS and iPadOS, in the future, but we're not there, yet. A single codebase is still good for both.

They test a Bluetooth framework[3].

It probably took me around a week or so, to write each one. They are pretty damn good. I think they are all "App Store ready."

I decided to actually go ahead, and create a set of apps, based on these[4], [5], [6].

I spent well over a month, on each, after merging over the test harness codebases, to make them ready for the App Store. Lots of UX testing, removing code that only applied to testing, and adding "friendlier" user interface.

I'm working on an app that I started about a year ago. Actually, I started it over ten years ago, if you include the two servers that I wrote, upon which it depends.

One of the reasons that it has taken so long, is that I have truncated months of work, and tossed them in the garbage, because they were not the proper way to go. I have an "evolutionary design" process[7], that means this can happen. I plan for it. I've probably shitcanned three months' of work.

Another thing that I do, is have an "always beta" approach to Quality. I maintain the product at "incomplete, but ship Quality" status for as much of the project as possible. In fact, I've been sharing it with the team, using TestFlight, since Oct 3, 2020 at 7:47 AM (I got that from the TestFlight metadata).

That means that the app has been stable and robust enough for user testing, and approval for basic App Store release (TestFlight External Testing is a more relaxed standard, but try pushing out a crasher, and see how far that goes).

I add localization support, accessibility, Dark Mode support, leak testing, etc., at every turn. It's very useful, because I can solicit immediate feedback from non-tech team members. It also means that the "basics" for App Store release are constantly being tested and validated.

Even more useful, if we want to ask for money, it's dam easy. We just loop the person we're begging from, into the TestFlight External Tester pool, and they can run the app without a Marketing chaperone, or sacrifices to the demo gods. We can also get valuable feedback from them.

It's really, really nice, and it has been, for many months.

I feel like we are now at a "starting point." Even though it has been a fully-functioning, release-ready app for the last couple of months, it need the "MVP treatment," where the testing pool is expanded, and we start applying it to "in the wild" scenarios.

Lots of companies use their customers as guinea pigs for the first several releases; usually by shoving baling-wire-and-duct-tape junk down their throats (and making them pay for it), before hitting their stride. It's a deliberate strategy. Some months ago, I read a post, here by a founder, declaring that "if you don't get physically sick at the quality of the code in your MVP, then you are spending too much time on the code quality."

Basically, deliberately write garbage, and force it on your users.

One of the reasons that I took on this project, was the founder is a friend of mine. He is running it as an NPO (501c3), and putting his own money into it. He doesn't really have much of it, to begin with. Also, more alarmingly, he didn't actually have a particularly good idea of what, exactly, he wanted the app to be. That's a recipe for disaster.

He asked me to help him vet some development shops he was approaching, to realize his vision.

It was eye-opening. He got a number of ridiculous quotes. I know what is necessary for this type of project (not small). For example, when one said that they'll deliver a full multi-server, multi-client app for MVP in three months (firm), upon getting a vague, hand-wavy requirements spec, it was hard for me to keep a straight face.

After a few of these, I just got disgusted, and said "Screw this. I'll do it." I've been developing it for free, as a native iOS/iPadOS app.

He has to pinch himself.

[0] https://stackoverflow.com/story/chrismarshall

[1] https://littlegreenviper.com/miscellany/testing-harness-vs-u...

[2] https://github.com/RiftValleySoftware/RVS_BlueThoth/tree/mas...

[3] https://github.com/RiftValleySoftware/RVS_BlueThoth

[4] https://apps.apple.com/us/app/blue-van-clef-for-mobile/id151... (iOS -Includes Watch app)

[5] https://apps.apple.com/us/app/blue-van-clef/id1529005127 (Mac)

[6] https://apps.apple.com/us/app/blue-van-clef-for-tv/id1529181... (TV)

[7] https://littlegreenviper.com/miscellany/evolutionary-design-...