Looking into the Digital Graveyard

It's amazing how much cloud software is heading to the graveyard. Yahoo Notepad, which have been around since the 2000s is being retired. I have notes in Notepad that predate 2010 so it's at least that early. For context that's at least four years before Microsoft OneNote and three before Google Keep. I think it could be older but I'm having a hard time finding a record of Notepad's launch date.

Salesforce's Quip is also on the chopping block. I covered Quip in the 2010s, long before it was part of Salesforce. I liked it a lot and even used it for a real project. It could have become the next Notion, but Salesforce didn't really know what to do with it. They were just into "collaboration" at the time and grabbed something.  This was at roughly the same time that Zoho was expanding, and Google, Dropbox, and Box were adding document-based collaboration. I guess they thought they could get in on that too. It made just about as much sense then as now.

Microsoft Whiteboard just recently died. It's hard to believe that it launched 12 years ago. The Google version, Jamboard, bit the dust a few years back. The whole digital whiteboard thing seems to be done like dinner. At the time Whiteboard was launched, it was tied to the giant screen conference room table project, Surface Hub, that Microsoft was pushing back then. Those were happier times before the pandemic showed us that no one really wants to collaborate in person, especially around a giant embedded screen in a table. 

Frankly, I surprised as many of these have survived as long as they have. The 2010s were the era of collaboration, driven by the notion that if you give people collaboration tools, productivity will be higher.  This was also the age of the intranet, intercompany information portals that facilitated information sharing. Very few of them are still around, mostly replaced by other software. Chat apps first appeared at this time too, though many of them have not survived. Slack mostly won and Teams killed off any of the laggards. There are still some left, but they don't have the market share of Teams or Slack. The same is true of video conferencing which is now dominated by Zoom and Teams.

What the business school types didn't get was that there is a time and cognitive overhead to using many of these products. Checking your email, intranet, chat, and other apps for messages and acting on them absorbs both time and brain share while diminishing attention to any one task. As usual, the market also had just too many big folks chasing the same thing. Why use Quip in Salesforce when I have Microsoft Office 365 or Google Workspace to manage documents? You even have the choice of Zoho, Dropbox, or Box if you happen to hate Google or Microsoft. 

I admit that, at the time, I drank the Kool-Aid a bit. I saw a lot of promise in these new collaboration tools. There was promise, but it wasn't clear which would prove to be the way people want to work together. It got overhyped for sure, but there was something to the idea of being able to work on documents and communicate better. Once again, the pandemic taught us that chatting and sharing documents were a good thing precisely because they could operate offline. We just didn't need twenty choices and "live" collaboration really means desktop video conferencing. 

The next market to experience the shakeout will likely be in the space that Notion, Microsoft Loop, and Jira (kinda) inhabit. These are glorified Wikis whose whole purpose is to bring some organization to otherwise free form information. I'm betting that Microsoft Loop won't survive even though I like it. Jira is heavily tied to the Atlassian software development project environment and Notion is good for general purpose project information sharing. Loop has very good functionally and has the best integration with the Office ecosystem. It just doesn't seem to be making a splash. Much of what it already does is available in OneNote and Teams. It's a Notion copycat and Notion is just a fancy Wiki. As Microsoft moves more of its R&D focus to AI, I don't see it spending money on Loop.

This type of category death is common. I found a blog I wrote back in the 2000s. It talked about not trusting SaaS services because they can just go away suddenly. This is still the same in the 2020s only with more services to kill. 

Keep in mind, this type of product death is different than the one happening in AI right now. That's an example of too many expensive products flooding the marketing all at once. That kind of shake out always happens before the market solidifies. What's happening in the collaboration market is more about killing off the stragglers in a mostly successful market. 

Call it the Hyena Principle. This is the final thinning of the herd. Yahoo Notepad was at the beginning of the migration and products like Loop are towards the end. Now that the migration is almost over, there still a few products for the hyenas to eat before they turn on something else.

Great Test for Project Nomad

Lately, I have been implementing my own set of computing services. Some of you might recall my NextCloud project to implement my own set of cloud services. I did that primarily to reduce my reliance on the cloud services of a certain company in Redmon, WA. It's not that I think that are evil or, at least, no more evil than any other tech company. It's just that all of these cloud service companies have a history of dropping and changing services that I've come to rely on. It was also good geeky fun.

In that vein, I've just completed a new project to implement information services as self-hosted services. The idea behind self-hosted information services is to provide access to important information when the Internet is unavailable. I could potentially turn off my Internet service or go out into some place off-the-grid and still have essential information. 

Now there are three classes of people who do this:

1. Techie geeks me who do it because we can
2. Folks who live somewhere that internet service is unreliable or unavailable
3. Preppers

Many of these systems deliver internet-based information to schools in places that have no or poor connectivity. The Preppers are something else altogether. These are folks who want to be prepared (prepped) for disaster. There is a bit of overlap with survivalists but, as far as I can tell, preppers are more about readiness then wanting to hide from humanity or the government. For the record, I'm in the first category.

There were a number of options for software, but I chose to use Project Nomad. Project Nomad is an open source control plane for implementing and managing other services such as Kiwix. It runs on Linux (because Docker) and I was able to use an old laptop that I had already loaded Ubuntu onto. Project Nomad is one of the easiest bits of server software I've ever installed. It sets up Docker containers, installing Docker, if necessary, asks what you want to install, and then just does it. Once the core software is in place, you can choose what content to download which happen in the background.

There are five major components, and you can choose any or all of them to install. They are:

1. An information library, including Wikipedia. powered by Kiwix
2. Maps from OpenStreetMaps
3. A drug database
4. A learning platform with content from Khan Academy
5. An AI LLM

I went with the information library, maps, and the drug database. The AI component was not going to run well on the hardware I had, and I really didn't care if I had AI support. The learning platform was just not something I'd ever really use. It would be different if I was trying to run a school in a caven. Any service can be removed or added later as well as a few other services such as Jellyfin media server and Vaultwarden password manager. 

The next step is telling Project Nomad what content you wanted to download. I choose Wikipedia, Wiktionary, some Stack Exchange forums on technical subjects, a bunch of categories of books from Project Gutenberg, a collection of medical information including military medical books, the iFixIt website, and a bunch of prepper material. That last bit of information was mainly out of curiosity. There was an entire set of videos on how to put together a bug out bag. It's not what I normally think about.

A lot of the information is useful to have around, internet or not. The real test came when I experienced a substantial ISP outage. Project Nomad meant that I had a lot of useful information still available and I wasn't floundering. It worked perfectly with no glitches or hidden connections to internet sites. The only thing Project Nomad couldn't do was pull updates for the software and content. That's to be expected. 

That need to pull information down, at least initially, is the Achilles Heel of Project Nomad. You need a stable internet connection to install the software and content. If you have your Project Nomad server already set up before the zombie apocalypse, then you're fine. If you didn't think about it until the manure hit the rotating blades then you're out of luck.

At the moment, Project Nomad is mild assurance against sporadic internet outages. It could also be setup by someone and shipped to someone else off-the-grid. It's easy to install and pretty low on resource usage, if you skip the AI. That's fine because when the robot apocalypse happens, I'll be trying to kill AI not run it off soar energy in my cave.

1. 
   

Microsoft is Not My Copilot

In the run up to Microsoft Build, I spent time trying out the new features of Copilot. I had already used Copilot in (as well as Qwen, Claude, and ChatGPT) in VS Code for development. It was useful for some of the more boring aspects of programming such as formatting output and the "scaffolding" of code. Other than that, you get a lot of bad code and have to spend time debugging code you don't know. Understanding that, I thought I had reasonable expectations of Copilots low code app and task generator. Alas, I didn't realize that even my modest expectations were setting the bar too high. 
Copilot Tasks and apps built around them is a great example of real value that AI could bring the average consumer or business. You tell Copilot about some activity that you want to automate, for example pulling information from the Internet into a daily digest, and any parameters around and "Voila!" it creates a web app to do it. While that sounds good in Microsoft's marketing literature, it doesn't really work that way.
The first problem is access to information. Now, if Copilot came back and said "without a connector or at least an RSS feed, we can't access the information" most of us would understand. This is, after all, technology not magic. Instead, Copilot goes along happily building an app for you only to have it not work. Ironically, sometimes the connectors to Microsoft's own products don't work, producing hilarious suggestions from Copilot. I tried to connect my Outlook account (I have a Microsoft Office 365 subscription) to Copilot to produce a digest of all my appointments and tasks for the day. It kept failing because Outlook insisted on 2FA for each query. Copilot being tagged a security risk by Microsoft's own products is funny enough, but it's suggestion that I switch to using Gmail instead was downright hilarious. I imagine someone in Microsoft marketing suddenly stopping whatever they were doing because they felt a profound disturbance in the force. It maybe it's the farce. Thankfully, Microsoft fixed that. Maybe it's what happens when you vibe code AI solutions.
Another strange problem is that Copilot doesn't seem to understand how to handle data even though the majority of their sample tasks and apps are data driven. In several cases, the data was pulled once and placed in an HTML CDATA block instead of using dynamic API calls. This meant that you had to rebuild the entire app or task in order to have it update. Copilot seemed to struggle with the idea of an app that updated daily not to mention on demand. Everything was hardcoded making it look right but completely static.

The Tale of Two Apps

I tried all kinds of apps and tasks as a test of what Copilot tasks and apps could due. I asked Copilot to create for tasks to send me daily digests of my calendar and tasks, create a web app to show me a daily list of calendar entries, tasks, and emails (data which comes out of one Microsoft application), retro skin a web site, and to create a list of all the baseball games for the day in both the major league and minor leagues with game times and where they can be viewed. Let me tell you about two of them.

Retro Me!

I love the website Hack A Day (hackaday.com). I've read this site for so long now that I can't remember when I began. It is likely about the time it started. I asked Copilot to skin it with a retro 80s BBS look. That would seem to be a fun homage to the site's maker content. 

Now it's important to know that Copilot takes a long time to create these apps. A really long time. Sure, you can go off and do something else while it runs but 20 minutes is not unusual for it to complete. This means every iteration of the app takes time and you have to expect that it will take several iterations to get what you want. 

After three iterations, I had what look like an awesomely skinned app. It correctly found the RSS feed and built around that rather than screen scraping the site. Copilot used the data to create something unique. It was great looking. Copilot used a black background with mostly green text and line characters to build something that could easily have been a BBS int he 80s. 

Like I said, it was great... except that it didn't work. You would click on and menu entry, get a list of articles, click through to the article only to get an "Oops! That Page Can't Be Found" message. Copilot was creating links for articles that didn't exist. When I told Copilot that it didn't work, it would claim to understand why, rebuild the application, but nothing would change. It would give elaborate explanations but never could fix it.

I checked the Hack A Day RSS feed, the supposed data source, and the articles that Copilot was listing didn't exist int he fed. I searched the site and found there were no articles with those titles, let alone on those dates. Copilot just made up the data. When told this. Copilot did the equivalent of making excuses and kept trying.

Keep in mind, you don't see the code, like you would if you were using AI to vibe code. I can ask it for the code (and wait 20 minutes again) but there's no guarantee that it wouldn't break later.

The big problem these errors represent is obvious. This is supposed to be used by non-developers as is all low code/no code solutions. Theya re not going to be able to guide the AI to fix bugs. They will just get irritated and give up or (and this is much worse) go about their merry way blissfully ignorant that they are dealing with poorly functioning apps or worse, incorrect or made-up results. 

Play Ball... Or Not. 

I'm a huge baseball fan. I have an MLB TV subscription and watch a game each day, sometime two. The biggest hassle is looking through all the available games in the major and minor leagues, seeing what times they are on and how to view them. Some games are blacked out in my region, some are only on a streaming service I don't have (real annoying since I'm paying for this), and some are on broadcast TV which I can then watch. That's a lot to look through each day.

I asked Copilot to create a list of baseball games in the major and minor leagues, that were available that day, noting which were on MLBTV, regular TV, or some other streaming service. Other features were filters for different leagues and blacked out games. It needed to be updates daily but also on demand, since schedules change. If Copilot had come back and said that it didn't have access that information, I would have accepted that. It's not like I expect Copilot to have access to the APIs for several different league web sites. 

Instead, Copilot happily went about building the app. Unfortunately, it built it stupid. It was able to retrieve the information from a set of APIs I didn't know existed but hardcoded the returned data into the app as CDATA blocks. That's not what "daily' or "refresh" means. With a structure like that, the app would have to be rebuilt each and every day (and there's that 20-minute time lag problem again). That's not exactly more efficient than just looking through the web sites myself. 

This is problem number two with Copilot - it makes poor choices that no human programmer would make. Even a recent college grad knows to only use CDATA for static data. Dynamic data has to be reread when you need it to refresh. No matter how many times I explained this to Copilot, it just could grasp the necessity to reread the data from the APIs. No software development manager would keep a developer around if they had to constantly explain exactly how to fix a problem and have nothing change. 

The AI Value Problem

This just outlines the main problem with AI adoption, especially with business. No one is going to spend money on something that doesn't return good value for that money. That's true with personnel and technology alike. If all anyone gets from AI is chatty searching, document summarization or intelligent email responses, then the ROI for AI is allusive, maybe non-existent. The ability to generate attractive apps that can act as business dashboards or consolidate information by just describing what is desired has a lot of value. Even current no code solutions still require work and a knowledge of the data sources that most folks don't want to get involved with. To have an AI product crank out personalized views of data is very valuable indeed, but only if it works right. Making up data, especially, makes it worse than useless. 

To be fair, Copilot Tasks and Apps are still in preview. Some bugs are expected. These issues, however, are fundamental. They are not minor formatting issues; they are showstoppers and time wasters. Let me say it this way: I have not been able to get a correctly functioning application out of Copilot Tasks and Apps. 

Conceptually, what Microsoft is doing makes sense. The devil, as the old saying goes, is in the details. If you can't get data handling right, can't access your own products, and make stupid programming choices that the most inexperienced developer wouldn't make then you have a demo or proof of concept, not a product remotely ready for general release or even a preview. 

I can't help but wonder how long consumers and business will put up with half backed AI while waiting for the promises to come true.