GSoC 2018 Cadence Holmes
Schedule - CST (GMT -5)
| Sun | Mon | Tue | Wed | Thu | Fri | Sat |
|---|---|---|---|---|---|---|
| Available | 10am - 5pm | 10am - 5pm | 10am - 5pm | Available | 10am - 5pm | 10am - 5pm |
I'm a music major. Well, I'm a PhD candidate in Experimental Music and Digital Media, but my degree will technically come from the School of Music.
I've never taken a formal comp sci or coding class, but I started programming for electronic music. It's been an up-and-down ride since then, and now I primarily do web and mobile development.
My work is most often for art and/or social justice/awareness/growth, but I'm always looking for new opportunities to learn.
I'm a multi-media artist. My portfolio includes music, visual art, installations, as well as mobile and web apps. I'm really interested in subversive processes where common tools and techniques are used in uncommon ways to produce new kinds of art.
As a researcher, I tend towards user experience and interaction design, especially concerning technology for STEAM education and informal learning.
Out-of-Character Contextual Information for PowerUp!
- I've met and chatted with several people!
- I've taken this time to become more familiar with the PowerUp iOS codebase and database.
- In order to move forward with my proposal, it was necessary to map out the current Q&A database. It turned out to be a bit of a pain to do manually, so I created a web app that automatically parses the tables and lays out the records in a connected tree. It's been a huge help to me in planning my time tables, but I think it's also going to be a big help as we try to clean up and improve on the current scenario writing. https://github.com/justKD/Sqlite-GoJS-DB-Map
- When forming my original proposal, I knew the writing in the current app could be improved on, but I wasn't aware of how fragmented the database was going to be. A big part of what I want to contribute is not just code, but also resources to use in order to improve the outcomes we could expect from the app. I'm having to rethink what that contribution might look like!
- Not yet. But I've started looking into helping with the scenario writing in general.
- I'm mulling over how to best help with the scenario writing. It's a little overwhelming for a number of reasons, but I started another web app that might be able to help with designing scenarios more efficiently.
- I'm also finalizing my design plans for the classes I need to implement. I want to ensure the new functionality leaves a minimal footprint on existing code.
- I think things are on track. Coding officially starts Monday!
-
I shared a different take on the mapper tool. The Sqlite mapper is still useful for checking the current state of the database, but I also have been working on a tool to help create and edit scenarios. I shared it with the PowerUp team at our weekly meeting. It's already been useful to me in creating dummy data for testing, but I think it can be used as a general tool for building and maintaining branching scenarios. Detailed description in the readme. https://github.com/justKD/powerup-scenario-builder
-
I started writing classes to handle the out-of-context events I've proposed. I've finished a working initial version of the popup controller. Right now the scenario view controller is checking for and presenting the popups, but they could also be added to mini-games.
-
I'm trying to build the class to be as easy-to-use as possible, and especially trying to leave the smallest footprint on existing code as I can. By subclassing UIView and using a delegate method, the view can be added and released all from an instanced variable rather than creating a strong reference to a persistent view. Here's an example of launching a popup:
guard let popups = PopupEvents().scenarioPopups[scenarioID] else { return }
guard let model: PopupEvent = popups[popupID] else { return }
let event: PopupEventPlayer? = PopupEventPlayer(delegate: self, model: model)
guard let popup = event else { return }
self.view.addSubview(popup)
/* Line by line, this code:
- retrieves the collection of popups for the current scenario
- retrieves/initializes a model
- initializes a local instance of the PopupEventPlayerClass, assigning the presenting controller as the delegate
- checks to ensure a everything's worked so far
- adds the view to the controller - the class handles it's own geometry, animations, sound, and interactions
- (the model provides strings, badge image name, and checks for sound)
*/
- It times itself for automatic dismissal, or can be tapped to manually dismiss it. Then it calls the delegate method where it can be removed from the main view, and ARC handles the rest.
func popupDidFinish(sender: PopupEventPlayer) {
sender.removeFromSuperview()
}
-
You can check out the entire class here: PopupEventPlayer.swift on GitHub
-
I added a new field to the Answer table for popupID, and have a model file to hold a list of the popup models. Something like this:
let popupEvents = [
1: PopupEvent(mainText: "test model 1",
subText: "has sound",
image: "minesweeper_abstinence_heart",
useSound: true),
2: etc.
-
The only changes to existing code were:
- Change the answer model to include the popupID field
- Change the database accessor to include a constant for the new field and return it in the answer model
- Call the function to present the popup when an answer is selected
- Declare the view controller as the delegate and add the delegate method
-
After finishing this class, I created test data and have been trying to put the class through the paces. It should always gracefully exit any functions (or just ignore a field) if anything is wonky, but never cause a fatal error.
-
I also updated existing unit tests to ensure they still pass.
- Nothing serious. It's kind of a pain switching back and forth between javascript and swift. They are similar enough in syntax to cause muscle memory headaches.
- I was looking into creating UI tests for the class. Setting them up is a little different from unit test cases, so it wasn't as easy as just adding a test class to the existing test target.
- I'm getting there. I just need some more time getting back into the Swift groove.
- I'm going to try and get the target for UI tests set up this week.
- I'm going to work on getting the UI test environment ready and design tests for the PopupEventController class.
- And I'm going to start work on the intro and outro story sequence classes.
- My original plan is having to change a bit since the current scenario content is evolving. I'm on track to finish the code infrastructure by the end of the first coding period.
- I finished a first working version of the StorySequencePlayer class. It handles stepping through a collection of events that each describe a scene. Each step contains a left and right component that describes an image, text, and animations. Similar to the PopupEventPlayer class, StorySequencePlayer is designed to be as self-contained as possible.
guard let model = StorySequences().intros[scenarioID] else { return }
let sequenceView: StorySequencePlayer = StorySequencePlayer(delegate: self, model: model)
self.view.addSubview(sequenceView)
/*
- get the collection of scenario intros and retrieve the correct model if it exists
- create an instanced StorySequencePlayer passing the delegate and model
- add to top view
*/
- I also wrote a class to help create animations. It's based off of a concept that I've used in objective-c, but I think swift improves it greatly.
- I'm using this class to animate events in the story sequences, but it could be used elsewhere in the app
/*
- The Animate class attaches to any UIView and lets it be animated using a pseudo-sentence syntax
- You can chain together events that should happen simultaneously using .function()
- And you can chain together timed events using the optional callback function then: {}
- Animate includes functions for basic transforms, as well as some other pre-designed more complex animations
*/
Animate(view, duration).setOptions(.curveLinear).rotate(to: 90)
let view = Animate(view, duration)
view.setSpring(damping, velocity).translate(by: [50, 0], then: {
view.flip().shake(then: {
view.reset()
})
})
- I'm not used to actually working with other people in a git project. I'm usually free to be sloppy and make random edits and changes without explanation, and then merging a big chunk of well-worked code.
- I think so. I just have to be careful and actually think about how I'm structuring changes in branches and commits.
- Tests for the new OOC classes.
- Still on track to finish coding the main infrastructure to handle OOC events by the end of the first coding period.
- I finished automated UI tests for StorySequencePlayer and PopupEventPlayer. They test expectations for user interaction.
- I've also finished unit tests for both classes. Since their general functionality is being tested in the UI tests, my unit tests focus on being thorough and asserting that the datasets are complete. I've set them up with the expectation that the datasets will be a part of the platform agnostic databases rather than hard coded in swift.
- The StorySequencePlayer test asserts that all strings from the database match existing options. It tests for media files (sound and images) as well as testing that the position and animation enums are matched.
- The PopupEventPlayer unit tests check each stored model by creating an instance of PopupEventPlayer and asserting that the correct elements exist and match the data we expect.
- I haven't submitted the PR for the unit tests yet because one of the UI test PRs is causing an issue. Even though the StorySequencePlayer test passes in Xcode, the Travis-CI check is failing. At first, it was because I didn't account for an actual new game not showing as many screens as starting a new game and overwriting old data, but now it's not entirely clear what the issue is. Travis fails when it tries to find a button to tap, but it can log the buttons data at that time, and running the actual test in Xcode doesn't have the same issue.
- The Travis check hasn't been resolved yet. It's just not entirely clear to me what is different between running the test in Xcode and what Travis-CI tries to do.
- I want to get this Travis thing resolved for sure, but otherwise I have a couple housekeeping issues to deal with in the new classes:
- There's a bug in the story player text: when new text is generated, all text slides up and old text fades some. The issue is when the left and right events both have text. The left side is added first, and, even though it is new text, it fades right away. I've got a fix in mind and will implement it soon.
- Then, I need to add in an example outro sequence. That shouldn't be a big deal since the event is the same as an intro, but the way it is launched is different and needs to be tested.
- Finally, I want to move the datasets to an external file that could be used cross-platform. Right now they are just hard coded in the app. I need to move the data and create the functionality to parse them.
- (I also want to create examples of how I envision these story sequences could be used. I think there's opportunity to use them in different ways.)
- Still on track to finish coding the main infrastructure to handle OOC events by the end of the first coding period. I should then be able to start documentation beyond the in-line comments and markdown, and to prepare issues to help port the classes to Android.
- @sunjunkie discovered the issue with the UI tests was due to differences in OS versions. It took some time to hunt down, but the fix ended up being pretty simply. You can find the details in PR #284.
- I've worked on some issues with the unit tests, and submitted the PRs.
- I created an example outro sequence, and updated the scenario view controller to handle outro sequences. Unlike the intro sequences, they change the life cycle of the view controller which required some rethinking in how it would handle that.
- I fixed text fading too soon in StorySequencePlayer. I described the issue in last weeks wiki update.
- I'm having another issue with Travis-CI, this time with the Popup unit test. I'm testing the popup dataset by creating every popup and testing that they have things where they should be and are playing sound if they should. It's passing locally in Xcode, but Travis fails because it doesn't have audio routing and can't create the audio player. I'm looking into options, but this test may not be that beneficial anyways. Testing individual components of the class may be enough instead.
- The Travis check hasn't been resolved yet.
- Resolve the new issue with Travis tests
- StorySequencePlayer needs an update due to an oversight. It doesn't handle swapping character images between steps well. Right now, the best way is to hide an image, change it, and display the view again. I'd like to have a way to script an instant change and appropriate animation in the model.
- I haven't gotten to moving the datasets to an external file yet. Now I'll wait to update the StorySequencePlayer model, but this is still something I want to start working on this week.
- (I also want to create examples of how I envision these story sequences could be used. I think there's opportunity to use them in different ways.)
- The main infrastructure for handling the events is essentially done. Intro sequences work, outro sequences work, and popups work. The issues with Travis have set me back a bit, but not much. I do want to do this small redesign on StorySequencePlayer, and I still need to add the functionality that will support cross-platform models. In the next phase, I want to get solid documentation for scripting these events and how to implement them. Originally, I had wanted to help add content to the scenarios using these classes, but since the scenarios are changing fast, and new ones are being added, I think it might be more beneficial to work on the scenario design lifecycle. The tool I created to map and export scenario dialogue is already a start for that, but I'm thinking it might be useful to have another tool to better design and create popups and story sequences. Right now you would still have to script both in the format of the model.
- The issue with Travis is resolved, but I had to change the unit tests to not invoke the sound api. I think it makes the test less useful, but the classes are changing a little, so I need to re-evaluate the tests in any case.
- I've updated the classes to parse json into the swift models, so the popup and sequence scripts can be cross-platform.
- I've worked on small fixes and code clean up in the new classes.
- While working on those things, I realized creating story scripts would always be slightly inaccessible as long as the data had to be coded in text, so I proposed a new tool to visually design story sequences, and export it in the correct json format. There's a good bit of work to do to make the whole process intuitive, but I think this and the scenario builder could make the process way more accessible to everyone, coder or otherwise. Everyone seemed responsive to the idea, so I'm going to move forward with working on it as an amendment to my GSoC work. Originally, I had planned to work on scripting and sourcing content for the scenarios, but they are evolving too fast to really do anything meaningful in that regards. I feel good about working on this design tool though, because it serves a related purpose and could have a larger impact on the project.
Over the past couple days, I've started working on an interactive mock. The general concept behind the interface for creating a single story sequence is pretty straight forward, but I'm concerned with how to handle organizing and combining them all into a single JSON that can just be dropped into the project. One of the biggest problems is properly identifying and connecting any outro sequences with the answer that will trigger them. The easy solution would be to just require the user to know and input that manually when creating the sequence, but I'd like to try and connect the scenario builder somehow. I'm thinking this could be a more connected environment rather than individual tools, but I'll start with just getting the designer to export a single script at a time. 😸
-
I haven't finished working on the issue with the "swapping images instantly" problem. It was a combination of getting side tracked with proposing this new design tool and wanting to get outstanding PRs checked in before moving forward.
-
I was planning on moving forward with public documentation on how to script for and use the new classes, but I think that should wait now. This sequence design tool will affect this process a good bit.
- Not yet. I want to think some more on the sequence designer and get some feedback on the interactive mock, so I'll tackle this soon.
- Tackle the issue with StorySequencePlayer image swapping.
- Finish initial designs on the sequence builder app and start working on that.
- I need to update my timeline since my proposed project is changing a bit. I think I can finish a stable working version of this sequence builder by the end of this coding phase, and then I'd like to tie it all together (the classes, the scenario builder, and the sequence builder) and create public documentation during the last phase.
- I finished solving the issue with swapping images in the StorySequencePlayer class. I had thought it would be easiest to just add an animation or position option to let the class know when to handle the swap, but I was never really happy with that since it would make it impossible to include a new position or animation at the same time.
The big problem was how to handle different versions of the same character if I were to automate the process. For example, you could have an image that was "character-happy" and "character-sad" as well as "character-2-happy" and "character-2-sad". I didn't want the hide/show to automatically happen every time a new image was used because of this.
Ultimately, I resolved the issue by requiring that character images for these sequences be named using the specific format "character-name^version". I think the carat is unique enough to ensure it doesn't get in the way to naming the file, but it allows me to separate the string components and compare when a character is different, not just the image. Then I added the logic to be able to automatically test for this, and if the character changes it hides the image, changes it, and shows it again accounting for any newly assigned position or animation.
-
I've started working on the new sequence builder tool. I finished an interactive mock to present to the team for feedback. Now I'm working on getting the live project up and running. It wasn't that big of a leap from the mock to going live, but since I used Webflow to create the mock, not all of the CSS translates directly unless I just exported the mock as code. Which would make it much more difficult to change in the future since it relies on a lot of things specific to Webflow.
-
After starting, I realized the CSS was getting out hand since so many classes re-used similar things. I backtracked a bit and am now using LESS to help consolidate things and make it more manageable and readable.
-
I also realized the back end would be easier to handle if it was built on a state/props library. I'm trying to make sure the CSS is also clear and contained enough to support that.
-
Aside from backtracking a bit when I started working on the live development project for the new tool, nothing really.
-
One of the concerns I brought up during our team meeting was how to integrate this designer with the necessary data for accessing it in the game. Creating and exporting the dataset is one thing, but as the scenarios evolved I was worried that it would become burdensome to maintain entry and exit points and which scene belonged where. The solution suggested in the meeting was to just focus on having one ending scene instead of multiple scenes. I think that's ok, but I'm also still mulling this one over.
- Yes. I'm moving forward with a more solid dev environment and nothing is obviously in the way.
- Get the CSS finished for the designer and get basic UI functionality added in.
- I still need to finish updating my timeline. I started working on that this past week, but I realized I was already making changes that would change anything I put down. I can better evaluate the timeline now though, so I just need to finish it.
- I've settled on using VueJS to handle some of the front-end work in the Sequence Designer app. It's robust and easy to include since it only requires a script to be included. I'm not really building it entirely as a Vue app though. Vue is being used in the simplest way to have the DOM watch and update along with datasources. It shouldn't require extensive Vue familiarity to be able to jump in and figure out what's going on. I'm still using jQuery to handle most of the DOM interactions, and organizing the app as a plain javascript project.
Vue is like React or Angular. It's less popular in general, but has been gaining since the release of Vue2 and VueX. Vue is used by the likes of Gitlab, Xiaomi, Alibaba, Grammarly, and Behance. Facebook and Netflix have also used Vue for some of their products.
- This week I've finished the static basic css classes, and I've started implementing basic functionality. So far, you can add and remove cards from the track, and focusing a card retrieves the data and updates the editing fields.
- I haven't encountered any real issues this week.
- Finish basic functionality - two-way binding for card editing, thumbnail track, managing multiple sequences, exporting to JSON.
- I've updated my timeline doc to show the new plans based on the new products I'm working on. I'm on track with the plan.
- The basic functionality for the sequence designer is finished.
- manage cards
- history/timetravel
- save/load state
- import/export work session
- I got a jump start on the next phase, which is to adapt the UI and functionality to an online storage solution. I've started building a new UI for handling save/load state.
- I haven't encountered any real issues this week.
- Finish the designer for a beta release for testing and feedback.
- Everything is on track.
- Story Sequence Designer app is functionally complete. Exports formatted json for use in PowerUp.
- All that's left is to add in-app help information. The readme documents known issues and future work.
- I haven't encountered any real issues this week.
- Clean up code and move the external tools to Systers repos.
- Address outstanding issues in the iOS PowerUp repo.
- Move to Austin.
- Everything is on track. Moving forward, I'll be cleaning up and documenting the work I've done so far, especially with clear examples of how to use the external tools to develop content and use it in PowerUp, and how to use the new classes I've added.
-
Added help popup to Story Sequence Designer.
-
Synced media assets and addressed an issue with property names.
-
Story Sequence Designer app is live. Tested creating a scenario, exporting the json, and importing/testing in PowerUp. We still need more thorough testing, but the app is officially a stable beta.
-
The Story Designer and Scenario Builder web apps now have repos on the Systers Open Source Github.
-
Addressed an outstanding issue in the PowerUp iOS repo. Adjusted PopupEventPlayer and dependencies to use sound file names rather than a bool. It requires a little more overhead to use, but now popups are more customizable.
-
Prepared slides and demos for Phase I/II demo recording.
- Moving this week was more problematic than it should have been. But I'm here and getting settled. I was behind at the beginning of the week, but I don't think it will affect my planned timeline.
- Yes. I'm close to being caught up again.
- Continue addressing outstanding issues in the iOS PowerUp repo.
- Thorough testing of all products, start to finish.
- Update code comments and prepare git issues for known quirks/bugs/enhancements.
- I'm on track to finish cleaning up the current live, stable versions of all products this week. This weekend I'm playing catch up on addressing old iOS issues, but I got a jump start on full-feature testing this week, so it should balance out. I expect to be on track to create official documentation in a week as planned.
-
Recorded demos for Phase I and II.
-
Converted issues for the Story Designer app from the readme into git issues.
-
Submitted PRs for outstanding issues concerning StorySequencePlayer and PopupEventPlayer.
- This closes all related issues and closes the epic.
-
Major code refactor in PowerUp Scenario Builder. Optimizations and readability improvements.
- Barring any significant bugs or other issues, these are the final builds for now. Consider this Public Beta 1 for both web apps.
-
Reviewed and made updates to other issues in the iOS repo.
-
Checked in on issues in the Android repo for porting features from iOS. There are four epic level issues:
- #1167 Port PopupEventPlayer.swift
- #1168 Port StorySequencePlayer.swift
- #1169 Port dependencies for both
- #1271 Port tests for both
No issues this week!
Begin working on public facing documentation.
I'm caught up and ready to create the public facing documentation for all of my deliverables. I've completed my timeline except for this final step.
- Created public docs for both web apps.
systers.io/powerup-scenario-builder/ systers.io/powerup-story-designer/
- Almost done with the public API documentation for the new iOS classes. Just need to move it into the git repo wiki.
No issues this week!
Finish the wiki for the Animate, StorySequencePlayer, and PopupEventPlayer public API docs.
Once this last item is checked off, I'll have completed all scheduled tasks!