Well, first week survived! I meant to write this on Friday, but I was mentally exhausted from work. And to be honest, I don’t particularly enjoy writing. However, we did make lots of progress last week: I began focused work on the Hendrix Today app, and Teddy began on the Lake Nixon scheduler app. This division of labor works particularly well for me; I don’t think I could keep up with or make any reasonable progress on five separate apps at once. This way, I can dive deep into understanding, fixing, and building one app in great detail.

It’s a double-edged sword, however, in that my mind is now filled with event cards and calendars and AppStates and Providers. Since I mostly work from my apartment bedroom, it’s easy for me to work over 8 hours a day, and I had some difficulty not continuing to work on Saturday morning. There’s still plenty of time left in the summer, and I need to avoid burnout, but when I encounter a problem I really want to see it finished.

For example, one of the many problems I encountered came from the Hendrix Today file structure. When I received the project, all the Dart files were in the project lib/ directory and a few subdirectories, and the files and subdirectories were all named in PascalCase. The Dart/Flutter style guide recommends that such names be formatted in snake_case, so I renamed all 13-or-so of them: Screens/SearchScreen.dart became screens/search_screen.dart, and so on. I committed and merged the name changes, including updating local imports to use the snake_case names, but other problems started popping up: Dr. Goadrich got build errors saying that the Event class was missing, and my VS Code git integration started acting funny in most of the Dart files. Also, any time I checked out the main branch or someone else’s remote, the subdirectories and Objects/Event.dart would be once again capitalized! That was the big hint: all the single-word names were unaffected by my change, except for on my local machine. As it turns out, Windows and NTFS file systems are NOT case-sensitive by default, meaning that git only noticed and pushed the changes I made to multi-word file names, since those changes involved adding a character (the underscore). I fixed it by forcing Git to be case-sensitive in its file/directory names using git config core.ignorecase false, and after that it was all back to normal.

The current challenge, which I’ll be picking back up tomorrow morning, is in the backend data flow. The original Hendrix Today newsletter linked to a Microsoft Form that allowed community members to submit events, announcements, meetings, and lost & found items that would be stored in an Excel spreadsheet. The spreadsheet would then be curated and converted into a newsletter (by hand, I assume) every evening. Although there is a lot of room for improvement, there are some large obstacles in the way, one of which is Microsoft Forms (henceforth referred to as “Forms”).

Forms, frankly, is a miserable excuse for a form software. It doesn’t support time fields and you can’t use RegExps to validate text fields, meaning there is no way to securely get valid time data from the user. The old form simply had an optional field named “time and location,” which then got renamed by the temporary Python script designed for Firebase uploading as “time,” which looks dreadfully confusing on the app frontend. “9am on the Bailey Lawn” is not a time, I can’t store that in a DateTime object!

There’s also a challenge with user input. The user, as you may know, is simultaneously the most ignorant and the most malicious person you will ever meet. They don’t know how to format a link, and they also know how to break any input parser or verifier you could write. From what I’ve brainstormed so far, the best solution to including hyperlinks in an event description may just be to have a human format it on the backend. My first idea was to support a simple Markdown-style link embedder, but I ran the idea by Teddy, and besides being a decent challenge to implement, it also wildly overestimates the average person’s familiarity with rich text formatting. At the moment I think my options may be:

  1. including a single “more info” hyperlink with each submission, or
  2. continuing the use of a human to format the hyperlinks for every submission.

I’ve been collecting questions about the design of the app I’d like to ask Communications (the Hendrix Today management group), and I think I should ask them about this issue before any further development, both to see what manual work they would be willing to do and to find the limits of the technology I can use in solving the problem. I briefly considered using a Google form, which supports date-and-time fields, but it still wouldn’t solve the hyperlink problem. It would also be leaving the Microsoft organization environment, which I think is necessary for ensuring that only Hendrix users can make submissions.

So that’s what I’ve been working on, and some of the stuff I’ll have to deal with this week. Overall I’m very glad with the progress we’ve made this week. Dr. Goadrich has worked on Hendrix Today’s UI, aligning it with the school’s style guide, and I’ve already learned a lot more about the design patterns needed to more elegantly build an app of this size. I look forward to seeing what progress will be made this week!