I have had a couple of users email me saying that Ink Calendar does not open any longer. The app will show the loading screen for a while, then close. I had been confused because these crashes were not showing up in my app analytics tool AppCenter, then it happened to me and here is the fix!
Navigate to this folder:
C:\Users\<insert your user folder name here> \AppData\Local\Packages\40087JoeFinApps.InkCalendar_b262nqv4g3cq4\LocalState
And delete the file “Microsoft.AppCenter.Storage” (or move it to your desktop or somewhere if you don’t want to delete it)
Open Ink Calendar, now it should work fine.
This solution is much easier than manually backing up and restoring the app and its data. I am not sure why the AppCenter data is causing the app to crash or how this state occurs. Mostly I am just glad I figured out what was causing some users pain and I was able to fix it.
As Ink Calendar has evolved over the years it has become a surprisingly complex app. There are different flavors of complexity and different ways to expect and handle what is going on in the app. Some of the types of complexity found in Ink Calendar:
Regional and language
File access and saving
Settings data validation
Broken Windows APIs
Control formatting and layouts
Rapid control creation
Bad error messages
Overly simplistic feedback
Each one of these types of issues poses their own challenges to solve and catch before Ink Calendar crashes. Solving a single bug report can take a huge amount of effort and before the work begins it can be difficult to predict the amount of effort needed.
Data from users or Microsoft AppCenter crash reports is invaluable when it comes to making progress in a timely manner. So much of bug reports however end up being “Unspecified Error” or “The error message for this failure could not be found” etc. The best thing is getting an email from a users who has an error and working with them to get it fixed!
I am the only one working on Ink Calendar, so progress is limited by my time, but I am dedicated to fixing every bug I can identify! Please reach out via email or “Contact Me” on this website. I always love hearing from users!
I have been hard at work on the next feature version of Ink Calendar. This version is bringing Journals, a feature which many users have requested for a while now. Unlike the other calendar views Journals do not have dates and are not tied to dates in any way. There are a few different styles to choose from and offer the flexibility to make Ink Calendar work for you!
The app has been submitted to the Microsoft Store now all I do is wait! As always thank you for using Ink Calendar and it brings me so much joy knowing people use this app every day!
Ink Calendar is a hobby project for me. I work as a mechanical engineer for my primary income. I would love to be an indie Windows app developer full time, but it doesn’t seem like that is in my near future. I am frequently trying out new ways to get Ink Calendar in front of potential users. An easy way this can be done is use online advertising.
In early May of 2021 I launched a Google Ads campaign for Ink Calendar. The ad directed people to this blog InkCalendar.com where the “Get From Microsoft” button is right at the top eager to be clicked. I ran the campaign for 3 weeks and spent $179 for around 883 clicks and 55k impressions.
To judge the ads performance I used the stats from WordPress, and initially I was impressed… then I dug a little deeper. Here are the WordPress stats around the time of the ad campaign:
5/10/2021 (campaign begins)
5/24/2021 (campaign ends)
At first look these stats are impressive! The weeks during the ad campaign had on average 6x more traffic! Exactly what I wanted! However I did notice there was not a similar increase in app downloads, so I checked to see if these new visitors were clicking on the link to get the app. Here are those numbers:
% of visitors click
5/10/2021 (campaign begins)
5/24/2021 (campaign ends)
These numbers were pretty shocking to me. The weeks during the ad campaign had no significant change in store link clicks. In fact when looking at what percentage of visitors clicked the store links the ad campaign had terrible performance.
I am aware advertising for Ink Calendar is not the same as general business advertising. Plumbers or restaurants in an area use ads to win customers from their very similar looking competition. I’m still not completely sure what is going on with this or what to make of these numbers. But here are the things I know for sure:
I am no closer to being a full time indie dev
I will never use Google Ads to promote Ink Calendar again
A side anecdote, I would wake up around 6:00am Central Time and by that time there were already a large number of views to Ink Calendar for that day. The ad only ran in the US and the new traffic to this blog was also only from the US. I cannot understand why I’d have a couple hundred of view before the day had even begun. Very suspicious in my opinion.
An updated was submitted to the Microsoft Store yesterday which contained a few key fixes bringing efficiencies to Ink Calendar. A newly discovered issue with Ink Calendar happened to be the way the Appointment Store was being used. Now I am calling a single instance of the Appointment Store which improves loading speed, memory usage, and appointment reliability.
There is more work to be done in this area and there are still strange behaviors with the Appointment Store API surrounding change notifications. I am trying to figure out what might be causing duplicate notifications when an appointment is added to the calendar.
Work to be done
I discovered today that adding appointments to the Windows calendar does not work well without an internet connection. Ink Calendar in the future will not enable appointment adding if the internet is not available. This should improve the experience as a whole because today the API simply fails with no warning or error.
Extra writing space has been a requested feature for some time, and it is a feature I have experimented with. Also adding text and hyperlinks to the canvas will eventually make its way to Ink Calendar.
I have been working on Ink Calendar since October 2017. Since then the app has grown to be much more capable and complex. When developing I expect there will be issues with my code, but as I have discovered there are also major issues with Windows APIs. In this post I plan to layout the issues I have been trying to fix for years with no success.
Ink Analysis Crash
One of the obvious hallmarks of Ink Calendar is the inking. Inking is different than traditional computer inputs like keyboard and mouse. A powerful inking experience requires quick selection and the ability to convert from ink to text. Lucky for me Microsoft makes this very easy with an API.
However this same magical API called InkAnalysis is the single biggest source of instability within Ink Calendar. My personal guess is this API is not heavily used because it has not improved or changed since I have been using it. Also Microsoft’s documentation on how to isolate the application from the InkAnalyzer does not exist. I have been working with the team to resolve issues; so far with no success.
Calendar API Errors
The other headline feature in Ink Calendar is the Calendar part. When users ink on a day and want to add that day to their Calendar in a more formal way there is a very easy API which can be called to add the appointment to the user’s calendar. However this API is frequently and randomly broken. No good feedback on a successfully added appointment. This means as a developer I have to guess if the appointment was added or the dialog was just canceled by the user.
Within the same AppointmentManager API is getting the user’s calendar appointments to show them on the calendar. This also is broken randomly and does not provide up-to-date appointment data. This completely prevents Ink Calendar from being able to provide a seamless calendar application. There is no clear way to connect with Microsoft regarding this issue and I have tried several different avenues.
Building UWP apps and submitting them to the Microsoft Store should be the easiest Azure Pipeline that exists, but it is such a terrible experience there is no wonder UWP was never widely adopted. When users finally get pipelines working they randomly break with totally unhelpful error messages “internal compiler error.”
Does Microsoft Want UWP Developers to be Successful?
It doesn’t seem like it. When compared to other platforms like iOS and Android, UWP devs have no advocates within Microsoft. All of the recent developer and technology investments have been made last and worst for UWP experiences. Azure DevOps, AppCenter, C# language, .NET 5, are best when not developing a Windows GUI application. UWP is ignored and abandoned. Microsoft’s own 15 year old framework WPF has gotten more support than UWP.
I want to be an independent UWP developer, but as time goes on it becomes clear UWP is the bastard child of Microsoft.
Finding and fixing bugs is a constant struggle with any software. It has been a painstaking process of narrowing down exactly what and where the bug resides in code. With Ink Calendar I group crashes into a few different categories.
Recently I was emailed by a user who mentioned OneNote was unstable until they turned off ink analysis. So in Ink Calendar version 2.0.7 there is a new toggle switch to disable ink analysis.
Turning off ink analysis should help with crashes. If you make this switch and it helps please let me know. The ink analysis is a Windows 10 API, so if there is an issue, I’ll collect what I hear from users and reach out to Microsoft.
Other than analysis issues file read/write issues are largely related to the Microsoft Graph which does the cloud syncing. I can improve the cloud service, but some things are beyond the scope of Ink Calendar.
Finally null reference errors almost all come from getting appointments from Windows 10. The Windows 10 appointments API has some issues with not getting fresh appointments. Also there maybe intermittent access issues resulting in null references. There is a helper in Ink Calendar which checks to see if Ink Calendar has access to the user’s calendars. Even though this check runs before attempting to get calendar data, the data can still return null.
If you are seeing consistent repeatable crashes with Ink Calendar I would like to hear from you so I can get to the bottom of the issue.
As always thank you for using Ink Calendar and please feel free to email me (support at inkcalendar dot com).
The biggest feature request has been cloud syncing feature. With such a big improvement comes a bump to version 2.0. Also on the way with this release comes a refresh to the apps icon set.
The cloud sync plan was going to be a custom hosted cloud service. However, the best long term solution for every option is the Microsoft Graph. Ink Calendar 2.0 will enable users to login with their MSA and sync via OneDrive.
All of the symbols throughout Ink Calendar are being refreshed with Microsoft’s new fluent icons. They are natural and fit the natural shape of inking better than the previous symbol set.
Work is ongoing and hopefully be finished soon. While I want this release to be perfect I also needs to get into users hands to increase their productivity.
For years I’ve been adding features to Ink Calendar making it more complex. At the same time I’ve been tracking and squashing bugs. This is the classic cycle of app development. With Ink Calendar 1.27 I’ve broken the UI elements into smaller chunks making it easier to reuse them and to find exactly where the bugs are happening.
Since Ink Calendar uses calendar data from Windows 10 that means many of the calendar views are drawn using async methods. Understanding failures in async methods via AppCenter can be tricky. By breaking down the rendering of each UI component into their own UserControl I’ve been able to narrow down exactly where errors are occuring.
Another way 1.27 is more reliable and robust will be in the settings page. The page loading sequence has been reordered to put the longest running tasks at the back and let data validation occur while those long running tasks are happening. Now working hours, agenda start/stop, and week start/stop times should all validate before saving bad data. This was an issue which can be hard to find on my development machine because usually the settings page loaded so fast, but personal usage on my Surface Go highlighted this problem.
The work done in 1.27 doesn’t bring any new major features to users, but should enable me to do some cool view blending in the future. Now that each of these controls are broken out on their own they can be inserted into different views in different ways. Look forward to a possible new blog post about how views could be changing.
As always, thank you for using Ink Calendar. If you encounter any issues please email support at inkcalendar dot com, and if you have any suggestions or ideas I’m always interested to hear!
Users have asked this question a couple of times. If you have ink on a day in the month view, then switch over to the week view, shouldn’t you be able to see what is written on the month view? Currently there is no mixing between views and this was a design decision but also a technical/UX roadblock.
The way I use Ink Calendar drove the way I designed the app. Year view represents my long term planning. When will I be traveling, when holidays land and how I’m going to use my vacation time. I use month views for daily tracking, jumping quickly between months and looking at what’s coming up in a couple weeks.
Week view is for hour by hour planning of the work week or weekend. When to expect things to come and go. Day view is used when I need to nail down a specific agenda for a day. Like there is a lot going on and I need to know where people are going to be and what is going on.
By these standards I have no need to see all of the different views overlapping each other. Generally I view Ink Calendar as a way to organize my thoughts and plans quickly and easily. When I need to share an event with someone or let it span views, then I add an appointment to my calendar.
Distraction and clutter free planning has always been a core design intent of Ink Calendar. I want to make it easy to jot down timelines and move them around. Overlapping ink from all different views on to a single view would not mesh with this design. Views would become extremely crowded and busy.
Technical and UX Roadblocks
Currently Ink Calendar relates one view to one ink file. Each ink file is loaded into an InkCanvas control. If I were to show week view ink on top of month view ink then any new ink would be added to the week view ink file. Parsing user intent on where they expect the ink to save and load gets complicated and nearly impossible to disentangle.
If the InkCanvas views were not overlapping, but laid out in some sort of side by side arrangement then there would need to be an InkCanvas control for each view. This could work, but it would make for a confusing user experience where a single pen stroke could not span the different views.
Ink Calendar currently can use a lot of RAM from loading views to the right and left of the current view. If one view contained the ink of four different views, then the RAM needs would be much larger. Since I typically use Ink Calendar on a Surface Go, I have no expectation that it would preform well, especially if there is a lot of ink.
It may be possible to have a merged view which shows all of the different views for a particular day. I have been looking into how to render views out as .jpg files. This could help the performance problem and give a unified view to show what is going on at every level for a single date.
If you are reading this and believe I have completely missed something or have a novel idea on how to solve this tricky situation then please let me know. I am going to experiment with adding ink between different views in different ways to see how it feels and looks, however I do not know how it will turn out.
Finally, throughout the development process decisions get made at every fork:
Should the ink be editable in a different InkCanvas or just view only?
Should year view ink be shown in the day view calendar?
Should I add a truncated week to the top of the week view?
What about the partial weeks at the end of a month, merge or overlap them?
Show the view-only ink as transparent?
Could users ink over the view-only ink?
Should that ink get shown on the month view?
All things considered this is a tricky problem where every users might have unique expectations. I’m not ruling this out as a possiblity, but I do not want to spend hours and hours on this feature which is only important to a small set of users. My time will probably be better used working on a cloud sync service or some other more broad appeal feature.
Please let me know what you think about all of this, and as always thanks for using Ink Calendar!