#vikingcodeschool

A week after my onboarding session with Erik Trautman for the Viking Code School FLEX program, I have already had the opportunity to participate in a codecast with Pinterest developer, Jessica Chan and refine my basic understanding about UX/UI.

Having built multiple Rails applications over the last two years, full-stack experience has presented itself in delightful and not-so-delightful ways. Over that time I’ve found that I really enjoy backend/devops/sysadmin and the logic of connecting systems of tools. Though frontend work can be fun and satisfying, I do find the pitfalls a little more frustrating. That makes a really great program, like what Viking provides, feel like breath of fresh air. It’s nice to have good guidance.

One part of the prep work in Web Design Basics introduces a process of tearing down the UX/UI of an application/site to understand the information architecture and how the interface experience meets the needs of its key users.

As I am also re-vamping my portfolio, I realized how many projects (both personal and professional) that could use some more work. After having a tear down party on the suggested practice of Twitter, AirBnB and Amazon, why not start with a teardown of one of my own?

Breaking it down

DailyRecord was created in part as a practice to learn how file uploads work with audio files and as a utility for my return to songwriting and recording. Let’s look at some questions that can help to break down and think critically about how the site meets or does not meet my goals. It should be pretty basic at this point, but this exercise will help me to understand and design the further improvement of the application. Plus I’ll start using it again!

NB: these are quick notes, please forgive the short nature of them. thanks!

1. Who is the key user? This isn't always clear, especially in marketplace sites, so take your best guess.

      - a person who wants to quickly and easily upload, listen to and share audio recordings

2. What is that user's number one critical goal when using the site? Be as specific as possible if there are multiple options here, e.g. "to purchase a red wagon" instead of "buy a toy".

      - to upload audio files       - to listen to audio files

3. What is likely to make that user's experience particularly positive (i.e. provide good satisfaction)?

      - easy & reliable uploader

4. What is the approximate information architecture of the site? (sketch it out)

      | HOME | Auth        |            |                  |       |            | Sign in    |            |                  |       |            | Sign Out |            |                  |       |            |                | Tracks | New Track |

      | USER |          |                                       |       |          | Track |                                       |       |          |          | Title                               |       |          |          | Reflection (Description) |       |          |          | File                                 |

5. What is the flow through that architecture for the user who is accomplishing the critical goal you identified above?

      HOME => Listen/Explore            => SignUp/SignIn => Add Tracks

6. What style(s) of navigation is/are used? Do they answer the key questions (Where am I and how did I get here? Where should I go next and how do I get there?)?

      - simple navigation is always present at the top of the site       - unless signed in, tracks are not present, unclear that home is an index       - navigation buttons do not change to indicate where on the path the user currently visiting

7. What key interactions does the user have? Are they clear and usable?

      - the key interactions available to the user are available from the nav         - Home (Listen to Tracks), SignIn/Up => Create Tracks         - again, "Home" does not clearly convey or encourage a user to listen to tracks

8. What did the site do well to allow the user to accomplish his goal effectively, efficiently and with good satisfaction?

      - the process is straightforward and simple for now, making it easy to accomplish the goals effectively. i would like to keep it this way as the site grows in complexity

9. What did the site do poorly when allowing the user to accomplish his goal effectively, efficiently and with good satisfaction?

      - a user may not know that they can create tracks unless they sign up         - there is a present dialogue at the top "Sign up or Sign in to add           your own tracks!", but it could be more present and wrapped up into a welcome/about message

    So, what have I learned about my application design? 

The application is still at a simple stage. I think that it can remain fairly simple, but I have some ideas for improvement of the UX/UI as well as some enhancement of the sites.

- TODO:

         - add welcome/about messages

         - update navigation to reflect the information architecture of the site

         - modify home to be a welcome page with exploration possibilities, but differentiated from the tracks index

         - add navigation to encourage creation of tracks, featured tracks to guide users to discover other tracks

         - add About/Contact

         - add community oriented features for interaction/participation

         - remove "Home" button, replace with "Daily Record" currently                below navigation

         - allow multiple file types, including open source formats

That was fun! Now to do some work on it!

https://github.com/son1112/dailyRecord

http://daily-record.herokuapp.com

Check it out if you’re interested and let me know what you think!

Hi! My name is Anderson Reinkordt. I am a software developer out of Lincoln, Nebraska. Self-taught, I’ve spent the last two years freelancing web development for local businesses, primarily using the Ruby on Rails framework.  

I’ve often thought how wonderful it is that, given the proper time and motivation, learning to code has always been within reach of our fingertips. I’ll never forget racking up my dad’s phone bill (in ‘95 we dialed out to Kansas City from Auburn, Nebraska) as I began playing with HTML markup more and more, getting that first taste of making textual changes in the background that changed the face of something that could be used, even if only for static content. 

Oddly enough, it wasn’t until 2011 that I installed my first Linux, had my first wireless card configuration problem, and thus my first breakthrough in understanding the logic behind the magic I had enjoyed for so many years. I saw the open door and I’ve been exploring ever since. 

Though I’ve come this far, I so often crave a structured education that solidifies the foundation for what I really want; to code for a living. I love doing it and I know that, with even greater effort, I can have it. So, I start onboarding to the Viking Code School FLEX program on July 18th.

Having already had a chance to meet and chat with Erik and Dara online, and taken the Prep work and coding challenges, I’m really excited about taking on this new adventure in my development as a developer.

8 weeks and counting!

This Sunday was the 2/3 mark in my stint at Viking Code School, and I’ve only been quiet here because I’ve been so insanely busy. Once the Rails portion of the course really hit its stride, the building was more important than the reading, so we started getting hit with 3 and 4 assignments a week, little sprints to learn particular topics all around the main projects.

Last post here was what, end of week 4? Yeah, in between, I learned how to throw together CRUD apps in my sleep, replace my hard-coded SQL queries with fancy ActiveRecord, play around with complex polymorphic associations, wrestle with API docs, roll my own auth 3 or 4 ways, grumble at Devise until it did my bidding, rack up 20 cents of Heroku bills spinning up a worker dyno to send emails in the background, tear my hair out over Amazon S3 policies— in general, to take off the training wheels and just start building things. 

This last month is mostly going to be focused on testing and JavaScript, which means that I know pretty much all the Rails this course is going to teach me. Curious how much that is? Fire up danebooking.herokuapp.com; that was the midterm solo assignment, when we finally went off on our own (no pairing), got thrown a bunch of Pivotal Tracker stories and simply asked to make a site happen.

This is a running work in progress post about what and how I set up my Macbook Pro to develop Rails applications.

Since we studied the Ruby language first in the Viking Code School curriculum, this is in addition to my previous post on my Ruby setup.

I basically did the steps as described on this excellent tutorial by Jump Start Lab (as recommended by dróttinn Erik at the Viking Code School) with some minor changes:

Homebrew's 'brew doctor' command indicated that I did not have the Xcode's Command Line Tools installed amongst some other misc warnings.  I didn't pay attention to those since I figured they would dissipate once I updated Xcode (and they did).

I updated Xcode and its Command Line Tools to the latest (6.0.1)

Ruby 2.1 - making it the default version via RVM (previously v2.0.0p481)

Installed Postgres DB

Additionally I made the following aliases in my .bash-profile file so it's easier to start/stop/check the Postgres server:

alias gopostg alias stoppostg alias statpostg

Addendum:

Following Michael Hartl's guide: Ruby on Rails Sublime Text Setup Tutorial, I've added a couple of useful packages to Sublime:

Added SublimeERB

Added Alternative Autocompletion

I did not want to update Git (even thought the post encouraged it) because I am familiar with the version already in place and didn't want to chance breaking it at the moment since I have a mountain of work ahead.

Ironically, the post didn't mention the need to install Rails, but in fairness it was a Ruby tutorial not Rails. I had to look that up on Rails Guide's Getting Started with Rails page to make sure the command was the expected: gem install rails (it was and it installed 25 gems).

NB: Homebrew's 'doctor' call now shows me these warnings when run:

However, since I don't know if "everything [I] use Homebrew for is working fine..." or not (seems to be ok), I'm not going to follow up with the suggested 'prune/link/unlink' methods until I run into a related problem and/or I know more about the system first.

That's it for now; onward to the projects!

As I'm working on projects for the Viking Code School I'm customizing my Sublime Text 2 (ST2) with tools and various configurations to make the process easier.

Here's what I have so far:

Package Control - package manager

Sass - for Sass syntax highlighting, etc.

SublimeREPL - for bash, Pry & IRB (and others!) CLI terminals from inside ST2

Sublimipsum - inject Lorem Ipsum... into page copy

Git - Plugin for some git integration into ST2.

Ruby Debugger - Interactive debugger for sublime

Soda Theme - Dark and light custom UI themes for Sublime Text

with the Additional Features and Colour Scheme

Quick Look - Use OSX's Quick Look feature to view images from within the editor.

I've gone mad with power. Thanks to investigating every single comment and answer to this Stack Overflow post and combining key features of a couple answers, I have assembled a single Ruby method that handles nonblocking, carriage-return-free i/o beautifully for realtime little scripted games. BEHOLD:

require 'io/wait'

def char_if_pressed   begin     state = `stty -g` #turn raw input on     system `stty raw -echo -icanon isig`     c = nil if $stdin.ready?     c = $stdin.getc   end     c.chr if c   ensure     system `stty #{state}` # turn raw input off and                              #restore state   end end