#Coding with Nate

This is cross-posted here.

#Adventures in getting your kids interested in coding

This is a series of posts I hope to do cataloging some of my progress with spreading the gospel of code to my kids. Recently I made some progress with my son, Nate, and hope to share what we build together in this series. 😊

#Part One: Idea and Schema

For many years, I've struggling in fits and spurts to get my kids to embrace coding. I took to it like a duck to water and was coding on this when I was 9 years old:

Behold the Radioshack TRS-80

I've had a few glimmers of hope, like when they were in robotics and were helping to write the programs, but eventually that died out. Then I had a brief period where my sons were doing lessons on freecodecamp.org. That site is fantastic, by the way. But so far, nothing lasting. But I press on.

#Something we both like

About a month ago, I challenged my sons to come up with an app idea. My thinking was that they might be more inclined to learn something if it would result in something that originated from their imagination. My son Nate started doing the Swift Playground lessons and things were looking up. But as usual, things sputtered out.

2 weekends ago, we were playing our favorite collector card game, Marvel Legendary. I have amassed pretty much the entire collection and we spent a fair bit of the weekend battling supervillains. There have been some apps made by the community already - namely one called Assemble. It randomizing matchups, which is really nice for a game that keeps growing with 3 or 4 expansions a year. But this app was starting to slow down in its updating. Additionally my son voiced his frustration with not being able to search up cards by the text on them or by their features. Suddenly, I saw the light go on and he turned to me and said, "Maybe this is the app we can build."

Eureka! We had a problem that we wanted to solve and it was surrounding a topic that we both enjoyed. It was the perfect storm.

#Early Plan

So the basics for the idea are now there. We want a mobile app that will allow for in-depth searching of thousands of cards and that will also randomize setups of games.

Technically, here's the early plan: a database of cards built in Azure Data Storage, accessible from Azure Functions, via a mobile app built in React Native. We will open source the whole thing, so feel free to contribute or give feedback, especially if you happen to also play the game.

#Homework

My homework for Nate so far is to start going through the JavaScript lessons on freecodecamp.org. Send me thoughts if you have some better ideas. My thinking is for him to try and pick up some basics of JavaScript while we're building out the backend. While he's learning, he's volunteered to help with data entry. We'll see how long that lasts.

#Looking at Cards

Our first order of business was getting the data figured out. My first real teachable moment. We examined various cards and started making notes, first in bullet lists of the various types of cards and the properties we were seeing on them. Here are some examples.

Mastermind	Hero	Villian

As you can see, there are many various qualities and this is just a small sample. In fact, just at the top-most level, there are 10 types of cards: Wound, Token, Officer, Sidekick, Bystander, Scheme, Enemy Leader, Enemy Support, Enemy Group, Playable. Pretty quickly in, we switched to a JSON document and started going over samples of each card type, appending properties to the same single JSON as we discovered new things on a card. This actually sunk in with him. Seeing the JSON get updated live as we were reviewing information on a card was like seeing the objects and properties come to life real-time on the screen. Here's what we ended up with:

Seeing as we will have to start simple, we will begin by manually creating JSON docs for cards, until we get a UI going. So to try and make it easier on us, especially Nate, I set out to make a schema for this sample doc. This route would give us intellisense and document validation in a good editor, like VS Code.

#JSON Schema

This was my first foray into JSON Schema. I started at the source and read through this walkthrough: Getting Started Step-by-step. That gave me most of the tools I needed to understand what was going on. Essentially, you're setting up type definitions and other rules as you identify them.

That said, it was still a pretty big doc for me to try and render out the schema manually, so I started with a schema generator - found here - and applied changes from there, namely titles and descriptions, as well as identifying things we missed as I was validating fields. The generator helps a lot with following along, as you can compare your node to the schema generated. The only big thing I had to learn how to add was the enum property. This is a great option for string properties. It allows you to provide an array of options for editors to leverage. Here's an example:

And here's what happens in VS Code when you reference the schema and attempt to add a color field to the document:

Pretty cool, huh? Well I thought so at least lol.

#'Til next time

So far, the schema is all we have and we're starting to create the data for Azure Storage. I'll share more as we make progress. Hopefully he stays interested and we actually produce a working product in the App Store. We shall see.

The full schema is published here: https://homol.work/json/legendarydb/card-schema.json

#Tee of the Week

Behold my newest edition! Took forever to arrive, thanks to good 'ole 'Rona, but still worth it. Seriously, where the hell is Don, Carole?!

#Tee of the Week

I've gotten lots of mileage with this one and it's still one of my all-time favorites.

#Discovery

Recently, I was tasked with discovering the needs of a customer in order to assess their current state in SharePoint Online and needs for the future. This was for a collection of technology groups that performed a wide array of services for other employees within the company. Early on, we knew that much of what we were evaluating was a lack of access to these services via SharePoint, so much would be created for the first time. Additionally, for the content that did exist, there was a lack of understanding in where the items could be found. Another interesting issue was the lack of understanding of the functions of these groups. Basically, a number of interesting problems, but largely centering around the employees being serviced, or their customers, if you will.

#To the Hub!

Based on the feedback, particularly around wanting consistency and knowing that there would be a hurdle with getting folks to know where to go, we decided early on to use a Hub for the job. It solves so many issues out of the box: consistent look-and-feel, consistent navigation, the ability to roll up content from spoke sites and search scoped at the hub level, among other benefits. But just because we now have a spot for folks to come and a place where maybe things look better and more consistent, it doesn't mean that they will suddenly know what to do. Part of the art of helping folks with SharePoint intranets or portals has very little to do with the tooling that is or isn't available in the 365 platform. Much of it is a User Experience and an Information Architecture problem. This may be my heavy marketing background at play, but it felt critical to me to deal with the hub needing to be customer-centric from the get-go, particularly the navigation.

#Ways to Solve Navigation

There were many thoughts on the navigation, both from stakeholders and discovery. The default thinking around the Hub navigation was to break it up by the various domains or spheres of teams that were solving problems or serving customers. One of my first thoughts on navigation was to look into taking it towards a task-based navigation, as it seemed like customers may only know what thing they may need to do. In my UX research, I encounter the following 2 articles that I wanted to highlight:

Object-focused vs Task-focused Design

Audience-Based Navigation: 5 Reasons to Avoid It

These are great resources for gaining insights into user habits and trends. So what is actually the best way to have a navigation that keeps the customer at the forefront?

#Topic-based = Customer-centric

The bottom-line is that typically task-based navigation can be very confusing to most users. So that was a wash. What becomes clear from UX research is that there isn't always a silver bullet. But UX is an iterative process. So let's find a solid starting point. Based on those articles and knowing that we still needed information to be somewhat grouped by communications site spokes - we still need to be thinking about the authoring challenges too - it seemed like our best starting point would be to go with topic-based navigation. This would allow the sub-options to still be domain or sphere-based, but should provide a customer with the terminology that they can relate to. The customer needs to see words that represent the things that have brought them out to the hub.

#Example

Let's look at a quick example of one of these domains: a group that we will call PMG. They were responsible for presenting resources pertinent to PMs and the PMI certifications including in-house governance resources. Originally, we had a top-level navigation called "PMG" with sub-options. But instead we landed here:

As you can see, the topic of "Project Support" aims to be a topic that should gravitate these PM users' eyes to the item that matters most to them. Is it fool-proof? No. But it's a solid start.

#Final thoughts

IA and UX is 2 parts science and 1 part art, in my humble opinion. I have worked on countless websites (namely at Brown Bag Marketing) over the past 10 years with Creative and UX resources. I've seen the sheer amount of different opinions mixed with a bevy of different facts, which also tend to change. But some things have remained true: the customer needs to be at the forefront and the calls to action need to be clear and take precedence. These are just some random thoughts in that arena. Hope you found it useful.

#Tee of the Week

This week’s tee is off to a great start today. Got some compliments and laughs at the doctors office. 🤪

My journey with blogging has been a complete mess so far. But I keep trying, so I guess that's something. Like so many people, the busier I get, the less I think about doing this. But I want to make this a better habit because it helps me reenforce the types of creativity I espouse.

For a long time, I've used Tumblr, but that just seemed like I was taking it too easy. My alternative has also been to piggy-back on my company's blog - again, also too easy, and just doesn't feel like "me."

So I set out to finally make my own site, which could start to be a little more "me" and start to allow me to combine having my own presence and be built on the things that give me joy.

Throwback post from Tumblr

Yesterday I posted a hopefully proper walkthrough for Office developers wanting to dive into React hooks. Check it...

https://threewill.com/function-components-and-hooks-architecture-tutorial/