EDIT: June 2024 - I've recently renamed the app to WristTrack, so updated the thread title, but if you're jumping in from page 1 you might find 20+ pages referring to 'WristCheck', so thought I should signal that here!

EDIT: Since the app is now live on the app stores I thought I'd update this first post with links!
You can find the app on Google Play here, or on the Apple App Store here.

Read on for some background and an ongoing discussion about the development as I continue to work on (and hopefully improve!) WristCheck!




Original Post: Hi folks,

As you may have seen mentioned in Andrew's 'Definitive Nerd Thread', I've been working on a wee mobile application to track what watches I'm wearing.

Initially inspired by some screenshots users were posting around new year, showing graphs of what they'd worn the year before, I wanted to create something similar, but couldn't find an Android app that would do the same... so I just spun up a spreadsheet to track things in the meantime whilst I built my own! (and as I've developed it using Google's Flutter cross-platform framework, the output works on iOS too!)

I've been using a dev build of the app daily for the past week or so (after slowly transferring all my stats into the app!) whilst I finalise a few parts of it, but it feels like it's pretty much ready to share with a wider audience.

A wee summary of what it does so far - note, all screenshots are from my phone running Android and set to dark mode - it also supports a light theme if preferred. Oh, and I can't see a way to make these images smaller, so apologies if they appear HUGE!

You can track your current watches, as well as a list of those sold and a wish list of those you might like to buy - you can also search for a watch (should your collection be large) or have it give you a random one: Track details of your watches including a picture (just one so far!):
Calculate a service schedule:
Graph what you're wearing most (as either a bar or pie chart): and get a wee overview of the state of your collection: It seems to work well, so while I finalise a few last bits and bobs, I thought I'd open it up to the forum to see if anyone fancies downloading a copy as a beta tester?

If you do, I've put together a short survey to fill in (as I'll need to collect your email address): https://forms.gle/LLgcT4VY5uLa475D6
(in fact, even if you don't want to join the beta test it'd still be useful to get some additional anonymous responses, as there are a few other questions in there... trying to pretend to be professional!)
(EDIT: The survey has now closed, however feel free to drop me a PM if you'd like to be added to the beta group for future releases - the more the merrier!)

I have a few bits I still need to do to get it submitted to Google and Apple (including getting a privacy policy drafted, creating app icons and prepping store images etc... all bits I'm rubbish at!) but hope to make this available in the next week, depending on how busy I am at my real job.

If there's interest I'll happily keep this thread updated with further progress too - and feel free to shout out if there are any other things you'd like to see this do!

Survey sent! I like the feature you have added for selecting a random watch to display. Great for those days when you just can't decide what to grab!

another completed survey here!

Submitted!

A question (or many more) if I may? I’ve tried a few different apps over the years and even used one for about 6 months, before eventually giving up on it. Most of them would have been fine for a collection of around 6 to 12 watches, maybe even a few more, but when the collection is something 80, 100 or even more, I ran into problems. With a collection of that size, most watches get worn only a few times a year, so graphs etc tended to be both very large and largely useless.

One thing that would help immeasurably would be the ability to filter, group and/or sort by attributes and have those groupings flow into graphing, reporting etc. For example, attributes (user definable attribute *values* would be good, rather than predefined ones) could be:

-Brand (e.g. CW, Omega)
-Model range (e.g. Trident, Speedmaster)
-Movement type (e.g. Automatic, Hand Wound, Quartz, HAQ)
-Dial colour (maybe even primary and secondary colours to account for things like panda or tuxedo dials
-Date last worn (not actually an attribute, but sorting this way may still be handy)
-Other suggestions?

Simple things like being able to sort the general usage display by brand and model would help immensely, as other apps I’ve used default to things like most recently worn or most recently created. With a large collection, this makes it hard to find the watch I’m after, so sorting how *I* want, rather than the way the app wants would be immensely helpful. This is probably the single biggest downfall of every app of this type I’ve ever used and the primary reason why I no longer use them.

Any attribute that can be used for sorting should ideally be available as a drop-down list with the ability to enter a new value, which filters to available existing options as you type, so they can be easily selected.

-Graphing and reporting where I could group by brand (or any attribute) (i.e. all CW watches added together, all Omegas added together etc; all automatic, handwound etc added together).
-Filter by brand (or any attribute) so that I can compare and graph (for example) all CW watches and only CW watches, or all (and only) quartz watches.
These reporting and graphing features (or rather the lack of them) are the second major reason I no longer use any app. Mind you, I’d like to…

The ability to edit and correct entries would be very useful, as most apps seem to assume that the date you enter a watch is the date you wear it, but I would often want to do the last two, sometimes three days at a time. The other issue here is that most apps assume you wear only one watch on any given day, which is not the case for me (and others here too). One watch a day, defaulting to the current date meant I couldn’t retroactively enter watches that I’d forgotten to enter the previous day, so allowing some freedom to edit dates and >1 watch a day would be great (essential for me if a want a complete data set).

One feature that I did like with some of the apps was a configurable reminder to enter today’s watch details. I found it quite useful.

You’ll probably read these and groan loudly (sorry), but I spent 35 years in IT writing and designing both corporate scale and small group IT systems, so I may take a different perspective with things like this (with a collection the size of mine, I almost have to) and I tend to look at multiple ways that people may want to (or need to) use apps, hence all of my suggestions.

I could probably come up with even more requirements if I spent some time (that I don’t have) on it , but I think these are a good selection of suggestions that I hope would make it a scalable, flexible app that people would want to use long term. How easy they are to implement however, may be another thing depending on what underlying architecture you’re using.

Cheers, Gary

Big thank you to everyone that's responded so far!

Gary - I'm super busy this morning, but I'll take time to reply to the above later if that's ok - I already have some plans (and things implemented) that I think support the above (for example, I've tried to keep the app performant for large collections and added a search feature to help find individual watches easily). As for graphs, mine purposely hide zero values to try to avoid too much info.

Will add a bit more about your by brand/model suggestions later (and I'll be honest, rushing out the door so haven't fully read your message! But it's a thread I'd love to pull on if that's ok!)

What an almost unbelievably talented group we have here. This is certainly something I will be watching. Hopefully this winter when things slow a bit I’ll give it a try.

So, going to write this post in bits as and when I have a minute, so apologies of it sounds disjointed!

To touch on a few points - like yourself I've spent a long time in corporate IT so know all too well that what gets built isn't always what was wanted (that's why I'm reaching out here - I've started by building what I want, with a few things added here and there based on comments and observations about other apps).

Firstly, making sense of a large collection - there are a few things I've implemented to make that easier.
I don't (yet...) have filters by last worn etc, but I do have both a 'favourite' list (can be added on watch creation, at the watch info view or simply by pressing the star next to the watch in the main list).

Secondly, I've implemented a (pretty awesome I think!) real time search option (see screenshots) that refreshes as you type, and searches on make & model.

Before:
After: Going onto your points about editing - I thought long and hard about the data model, and have used a noSQL document database, rather than a traditional relational one. Essentially every watch is its own object in the database, and owns it's own information and history.

This means I can easily do things such as:

• Allow individual fields of info to be updated,
  Allow full editing of the wear date history,
  Easily delete whole watches and all associated info without affecting the rest of the collection,
  Wear multiple watches on the same day

At the moment I've already implemented the ability to add and remove dates from the watches history, as well as made every field independently editable.
In terms of recording wearing a watch, there is a big 'wear today' button for simplicity, but adding in a missed date is as easy as calling up a calendar and adding them in

Let me touch on the note about filters for the graphs next - at day one all that the app will do is provide a filter by month and date, but I love the idea of an advanced search so will add that to my backlog!
If anyone is interested, essentially for each page of the app that shows anything watch related I begin by populating a list of watches and have different methods (sets of instructions) created to facilitate this. Some of them (like the current filter) take in additional information such as the month to filter on, and then return the list.
The page then makes use of its list to display things.

So, to do the 'advanced graphs' I just need to set up new rules, potentially a new page to show these and keep it isolated from what already exists.

Anyway, long story short I love the idea of advanced filtering and will absolutely commit to adding that in a future update!

I think the last point made is about daily reminders, I've not built those yet, but it actually looks pretty easy to do (and it would absolutely need to be an 'opt-in' feature as required the user to provide additional permissions on the phone)

Thanks again for the comments Gary, and please feel free to shout out if you think of anything else!

Survey done, looks like it ticks my nerd box

Thanks for the response! It seems like you’ve already covered some of my suggestions. Notifications, yep, need permissions, but they can simultaneously be some of the most useful, yet annoying things an app can do.

I know that many of my suggestions/requests are (yes, self-interest showing) based around large collection functionality, but I’ve found that most apps seem to handle smaller collections just fine; it’s once the numbers grow that the functionality starts to fail or at least be meaningful and/or usable. Interestingly most of the apps “performed” quite well with 100+ watches, they just didn’t give me any usefully presented information and became very inconvenient to use; for example finding the watch I wanted meant lots of scrolling. Also, my habit of owning multiple versions of one model (not just brand) meant trying to find that blue Trident, not the white one or the black one and typically, the names displayed are often the same for the first twenty characters (until you get to the colour) so I’d see one, check it to see if it was the right one only to discover it’s not and then silly things would happen; like the app would make me scroll from the very top again instead of where I left off.

From my understanding of them, the noSQL database should be able to implement any running changes easily and it should handle basically any volume of data any watch owner could throw at it. The filtering you’ve shown is perfect, looks like it fits what I was hoping for beautifully.

If it works as well as it promises to, I’ll be most happy to line up and buy it!

Why didn't I know that I ought to have a "thingy" in my life to do this stuff? I am surveyed!

Maybe the right 'thingy' just never came along before!

Gary, you make a good point about finding different versions (e.g. green C60 vs Blue) at the moment that might still be awkward if the name is too long for the space available (and I've not made a field to track colour, you'd need to add it to the name)...

Once I get the v1 out I'll have a think about this one too - an option might be to add a wee 'watch summary' pop-up if you long press a watch, so you don't have to navigate away from the search results until you're sure (although just checked and the search status does remain if you go into the detail then back:) )

As a wee update, since starting this thread I've written up a privacy policy (the apps stores demand these now - lots of searching and then a running it through a wee generator system to create one...), made the dark mode darker (to show true black, which is better on the battery if you have an OLED screen, and added in the watch archive/delete options, which allows individual watches to be either hidden or fully deleted.

Asked a friend to help me with an app icon and now I need to prep screenshots (in numerous different sizes...) and banner images for the app store submissions.

Still hope to get this submitted to the stores in about a week.

Those on Android that gave details for the beta would then receive an email from Google Play saying it's available (I think, only done this a couple of times and never actually fully released anything!) and it'll just appear in the app store as early access.

On iOS it's a wee bit different... They have a separate app called Test Flight, and you submit beta apps to this, rather than the full app store. Once submitted and approved (Apple may take a few days to say they're happy with the app!) again you should get an email saying it's available and Apple provide instructions on how to access it via Test Flight, along with any notes I provide them on testing.

All my iOS testing to date has been done on a simulator, so would appreciate if a few things could be checked out for me, but I'll confirm what as I get the release going.

Thanks again for your input and support folks - I hope this ends up as something you like and find useful!

A little midweek bump to keep you all updated - I finished up the weekend with a few minor tweaks to v1.0.0 and since then any spare minute I've had has been tied up prepping for an app launch. There's a stupid amount of non-development work involved in this and honestly I find it a bit of a grind (I'd rather sit in the dark playing with the code! )

So far I've focused on the Android side of things, but a lot of what I've done so far will be re-usable when it comes to submission on the Apple App store - for anyone interested, here's a wee summary of what's involved:

First, I needed to dig out my developer keys - this is essentially a small digital file I created last time I made an app (for my Open University final project) that allow me to 'sign' an app build - it essentially proves to the app stores that I am the developer that I claim to be - once I got these in place, it's a relatively simple case of updating some lines of code to use this rather than the default keys used to build debug app versions.

Next I had to log into the Google Play Developer console and setup some things for myself (updated developer declarations etc) as well as beginning to prep the app listing itself. This mainly involves a lot of surveys and paperwork (e.g. questionnaire to determine the app age rating; questions around categorisation of the app; questionnaire about app data permissions and usage etc) - all necessary stuff, but far from exciting!

Once that was done, it was on to the app screenshots! Things here are a bit easier with Google than they'll be with Apple - Google just wants a minimum of two screenshots - Apple want screenshots for different device sizes, which will involve trying to fit more simulators on my MacBook (pro tip if anyone want to try this - don't buy the cheapest MacBook Pro, make sure to invest in decent hard drive space as XCode and it's Simulators take up mountains of space!)

On Android I loaded a debug build onto my old Google Pixel 4 and populated it with fake watch names, so that I could demo functionality and grab some quick screenshots without risking the ire of any real watch brands (Rulex Submooriner anyone?)

I used a wee site I found to prep some nicely laid out screens like the below: For the Play Store I've got a wee row of four of these, highlighting some key features along with a banner image that Google might place somewhere (it used to be these banner images were on the app pages, I have no idea where they appear now!).

Then lastly I had to write an app description - now I'm no Copy Writer, so this is undoubtedly rubbish! However, hopefully what'll end up on the store provides a wee summary of the key features of the app.

At the moment it's all running with a placeholder icon, but on the Google side of things all that's left to do is create an app bundle (when I get the final icon - I've seen an early draft so hopefully will have that to upload soon!) and then upload it - so watch this space!

Whilst I'm waiting though, I need to do this all over again with Apple...

It’s the paperwork that takes all the fun out of life isn’t it!