Author: bartos.25@osu.edu

Homebrew doesn’t work in Mojave (MacOS 10.14)?

If you upgraded MacOS to the new Mojave, you might have found that the Package Manager Homebrew no longer works correctly for some packages. If the same thing happens to you, where you get build errors, you might have to run the following command:

sudo installer -pkg /Library/Developer/CommandLineTools/Packages/macOS_SDK_headers_for_macOS_10.14.pkg  -target /

Give it a try next time you need to build a package with Homebrew.

Running long processes without needing to be logged in

Ever need to index a large amount of objects overnight but don’t want to leave your computer in the office while is working?  Maybe you have a lot of commands you need to type and if your internet connection goes down, you have to start over from scratch?

Here is a quick and painless way to run a quick script without needing to be logged in while you’re waiting for it to finish.

First, VPN and log into the server you want to run a long process.

Then, enter the following command:

screen -R -D

Next, simply run the script that will take a really long time:

./this_script_will_take_many_days_to_finish.sh

Detach from the proccess with the following keystroke: “CTRL-A D

and logout:

exit

Check the progress

Anytime you want to check the progress of the script:

screen -R -D

And again, use “CTRL-A D” to detach from the process again.

There you go! If you have a long process or you simply want to be able to continue your work even if your internet connection dies, give this a shot!

A Bookclub Reading of Badass: Making Users Awesome

“Given competing products of equal pricing, promotion, and perceived quality, why does one product outsell the others?”

That is the question proposed by best-selling author Kathy Sierra, in her book Badass: Making Users Awesome.  Many teams might rely on a giant marketing and development budget, crazy PR stunts, wasteful requirements and design documents. What we learned in Badass, is none of that matters. The only thing that matters is the user. Here at Libraries IT, I facilitated the reading of the book Badass: Making Users Awesome to figure out how to do just that. Here’s what we learned along with how we can use this new knowledge to make our patrons more awesome.

Find the Larger Compelling Context

There are really two types of mindsets. The first mindset (MindsetA) is product-centric. The second mindset (MindsetB) is user-centric. MindsetA says, “this product is going to be awesome!” while MindsetB says, “our users are going to be awesome!”. MindsetB is the mindset to shoot for.

So, that’s all fine and dandy, but what exactly does that mean? What do we want our users to be awesome at? The answer: The Compelling Context. Here’s an example:

Let’s say you make amazing cameras. You spend so much time building an amazing camera. The design is beautiful, the features are fantastic, the documentation is so easy to use and follow. Bob buys one of your cameras. He loves it! He takes great pictures. He shows them off to his friends. And they say, “Wow! You’re a great photographer!” What they don’t say is, “Wow! You’re a camera expert!”

Let’s face it, people don’t use your product because they want to be good at using it. They use it because of what it allows them to do. People don’t buy cameras because they want to be better at using cameras, they buy cameras because they want to become a better photographer. The compelling context in this case is photography. The camera is simply a tool to help achieve that larger context.

At the libraries, we realize that our compelling context is getting patrons, faculty and researchers access to the the best resources and information as quickly and as easily as possible. We have a couple things in the pipeline that will help finding resources and information much easier and much quicker.

How to make users Badass at the Larger Compelling Context

So we know what we want our users to be Badass at doing. How do we actually get there? 

The book goes into great length into what exactly expertise means. It turns out being an expert is relative. You are an expert if you can do something more reliably than someone else. To stay on the camera metaphor, you’re a better photographer if you can produce more aesthetically pleasing and evocative photos more reliably than someone else.

Many people don’t want to be world-class at things. People that are searching a library catalog don’t necessarily care about boolean searches and advanced form searches to find what they are looking for. Sometimes, it’s enough just to type in a keyword or two while expecting a favorable result. As you can see, there are many tiers of expertise. It’s almost like belts in karate. Our goal then, is help and support our users to get better results, more reliably, over time.

Deliberate Practice. Or, Getting Better Over Time

Practice doesn’t make perfect, practice makes permanent. We’ve all heard something along these lines, right? Just because you do something, doesn’t mean you’re getting better. There is such a thing as better practice. It’s called Deliberate Practice. 

The goal of Deliberate Practice is to design practice exercises that will take a fine-grained task from unreliable to 95% reliability within one to three 45-90 minute sessions. An example might be, “Create, compile and run a program (without errors) that accesses and displays data from this database.” Either you can do it, or you can’t. There is no wiggle room. If you can’t get to 95% reliability in one to three 45-90 minute sessions, redesign the sub skill. It’s too big of a skill and possibly too difficult.

This Deliberate Practice could be developed with really good documentation, tutorials, and a few examples that actually get them the results our users actually want. We are focusing on quick wins for our users. Documentation shouldn’t be too time consuming, boring and fruitless. Documentation should provide a quick bird’s eye view of the product with the mentality that users want results more than they want to read documentation.

Perceptual Knowledge & Perceptual Learning

Our brains know more about certain things then we think it does. Have you ever tried to explain how you did something only to realize you have no clue what you know. You might have said, “I don’t know how I did it, I just did it…” This phenomenon is called “Perceptual Knowledge”. It’s very hard to learn the Perceptual Knowledge of an expert. The cool thing is you can learn without knowing that you’re learning. This is called, quite obviously, “Perceptual Learning”.

In 1994 two researchers, Phillip Kellman and Mary Kaiser from NASA presented a study designed around “information pick-up”. Seasoned pilots are able to glance at standard cockpit instruments and immediately extract enough information to know the plane’s situation. Within two hours, a group of non-pilots learned to accurately interpret the cockpit instruments faster than seasoned pilots with an average of more than 1,000 hours of flight experience. These weren’t novice pilots, they were non-pilots. They were able to learn in 120 minutes what others could do after thousands of hours of training. What was different about their learning experience? Participants viewed a cockpit instrument display, then chose one of seven responses:

  1. Straight and level
  2. Straight climb
  3. Straight descent
  4. Level turn
  5. Climbing turn
  6. Descending turn
  7. Instrument conflict (malfunction)

They received immediate feedback after their choice. So, each time they made a decision their brains were picking up patterns they consciously were unable to verbalize. They just knew what to do.

So, what does this Perceptual Knowledge and Perceptual Learning have to do with making Badass users? Well, in the context of finding resources and information quickly and easily, it’s possible to give users exposure to lots of high quality, good examples of search queries that would work. They will start to see patterns of good searches and good search results. They will start to learn without knowing that they are learning. You could even provide bad examples as long as those bad examples evoke a feel that something is wrong.

None of this stuff matters if our users don’t actually want to get better.  We need to keep them motivated to want to get better at this larger context.

Removing Obstacles for our Users

“The typical response to users dropping out is, ‘let’s double-down on the forward-pulling magnet’. Deeper discounts. Promoting more enticing benefits, etc.” This response is not solving the real issue. The secret to keep someone from moving forward, is to reduce the things that slows or stops them. The difference between the compelling context and where our users are at is what teams of product development should put most of their effort into. 

Before your user buys into your product, they are motivated by that larger context. After they buy into it, they could possibly lose motivation if they are stuck on trying to use the tool. Remember, it should never be about the tool itself. It should always be about the user and what they can do after they use the tool.

Room Reservation has a new natural language search tool. It’s designed to bypass a Calendar UI. You can type in things like, “rooms available from 3pm to 5:30pm on Friday” or “6pm – 7:30pm in Thompson Library” and you should get all the timeslots available. One obstacle that I attempted to remove is “how do I search”. And in response to that question, I have a popup that gives sample search terms. The other obstacle that some users seem to be having problems with is sometimes search queries simply error out. Most of the time, because the natural language syntax is wrong and the Lexer can’t figure out how to tokenize the query. The response to that obstacle is there are multiple ways of reserving a room — the compelling context of finding resources in the libraries. If the search isn’t working, there is always the ability to select any number of rooms and browse around the calendar UI.This search tool is still in its infancy and there are plenty of ways I can make it easier for the user to reserve the room that they want. These are not bug fixes in the traditional sense. They are simply ways of making our users much more Badass while closing that gap between being an expert in the compelling context and where our users are stuck.

Remember: “It matters less why they’re struggling than that they are struggling. Obviously, you’ll do what you can to fix the unnecessary pain caused by problems with your product or support. But until then, just tell them. They don’t need you to be perfect. They need you to be honest. What’s much, much worse than a bad user manual? Making the user think the manual works just fine for everyone else.”

Online Discussion Forums / JIRA

We use JIRA for bugs, change requests, feedback and everything in between. The nice thing about JIRA is that at times it’s basically a user learning tool. We can read and note all the things that are not going as planned. This is why I had the idea to implement a natural language search in the first place. Our users thought that having to click only three rooms at once was time consuming and slow. “Why can’t I just type in a time and date and it brings up everything available?” So, that’s what we did.

Focus groups and face-to-face interviews do not get you answers like online discussion forums do. When people are behind their monitor, they are brutally honest. This is exactly what our team needs to improve the lives of our users and we will continue to read and honor the feedback of our users.

The Path to Badass

The beginner’s path to the compelling context should be simple. It should give users a quick win and it should motivate them to learn more. Users should know where they are in the path to Badass at all times. This is one topic during our book club that we thought about quite a lot. We’re not talking about collecting badges and gimmicks like that. It might be worthwhile to give our users the opportunity to access more beta functionality and increasingly more complicated ways of using the product successfully.

“Of all the things that can boost emotions, motivation, and perceptions during a workday, the single most important is making progress in meaningful work. And the more frequently people experience that sense of progress, the more likely they are to be creatively productive in the long run. Whether they are trying to solve a major scientific mystery or simply produce a high-quality product or service, everyday progress — even a small win — can make all the difference in how they feel and perform”
— Teresa M. Amabile, Steven J Kramer (The Progress Principle)

One way to think about facilitating the progress principle is to think, “what can our users do in the first 30 minutes of using our product? how can we support them to accomplish something in the first 30 minutes?”

Back to the camera example. We would rather our user be able to take pictures in the first 30 minutes rather than taking 30 minutes to read the manual. Quick win for the compelling context. If we could do that, the user will show his friends his pictures. Now, he’s not necessarily a badass photographer, but who’s to say he’s not a photographer? Win – win.

Proper Design

In 1999, Professor Baba Shiv and his co-author Alex Fedorikhin conducted a simple experiment with 165 grad students. They were put into two groups. One group was asked to memorize a two digit number and the other group was asked to memorize a seven digit number. Afterwards, they offered both groups a snack. All participants were able to pick either something healthy or something not healthy. The participants that were asked to memorize the seven digit number was an astounding 50% more likely to pick the unhealthy snack versus the healthy snack. The conclusion of the study is that willpower is a muscle.

What does this have to do with products your users love?

If you have to sit around trying to figure out how to use something, it’s going to reduce your willpower. It’s actually going to prevent you from wanting to use that product. Our goal at the libraries IT is to prevent people from trying to figure out how to use our products. How do we know that people aren’t able to use our products to compel us to change something here or there in our products? Feedback! The more feedback we get from people like you, the better we will be to make our products easier to use so that you can become badass. Remember, the easier our products are to use, the easier our users will be able to get better at the larger context.

Conclusion

The point of Badass: Making Users Awesome, is to change your mindset away from the products and apps that you create and instead focus on the user. Your user doesn’t use your app because they want to use your app. They use the app because they need to achieve something, their larger context. You don’t use Facebook because you enjoy wasting your time on Facebook (the tool). You use Facebook because you want to connect with people that you don’t usually connect with (the larger context).

The way we do this is start with feedback. Figure out who our user is and what they actually want to do. Once we have that data, we create and update our applications to remove as many obstacles from our applications as possible. Our goal is not to make Badass products, but to make Badass users.

Thompson Library Pilot for Group Study Room Reservations

This evening at 5:00pm there will be some brand new changes to the Room Reservation system. Some changes are changed specifically for Thompson Library.

A new service will be piloted at the Thompson Library this fall, offering students the ability to reserve group study rooms in Thompson on the same day. The seven rooms on the ground floor of Thompson will be incorporated into the pilot, which will run through autumn semester. Room information is available at go.osu.edu/THO. The page also provides information on the number of computers available at Thompson at any given moment.

  • Requests made to the Thompson Library group study rooms will be automatically approved if information provided is correct:
    • Email addresses are in the osu.edu or buckeyemail.osu.edu format
    • The number of participants are at least as much as the minimum occupancy for the room but not more than the maximum capacity for the room.
  • Thompson Library now supports same day, same hour reservations. If there is a room available today, you no longer have to wait 24 hours before using the room. Simply schedule the room whenever it’s available!
  • Statistics will be available for administrators that shows the number of students requesting same day reservations and the number of students reserving reservations in advanced.

Some additional changes are in effect for all libraries as well:

  • Students will be able to schedule multiples times in a day as long as they don’t reserve multiple reservations for a single day. This fixes a bug that prevents users from scheduling more than one reservations at one time.
  • Reservation titles are automatically generated. It will be in the form: reservation # – name.# of the user making the reservation.

Setting up RSpec / Guard for Writing Automated Tests

 

This is how to set up RSpec and Guard in your Rails application for getting started in writing automated tests.

In your Gemfile, add the following:


group :development, :test do
gem 'rspec-rails', '2.14.1'
gem 'spring-commands-rspec'
gem 'guard-rspec'
gem 'rb-fsevent'
gem 'fabrication', '2.11.3'
gem 'sqlite3'
end

group :test do
gem 'capybara', '2.4.1'
gem 'faker'
gem 'shoulda-matchers'
gem 'selenium-webdriver', '2.43'
gem 'capybara-webkit'
gem 'database_cleaner'
end

Then,  run `bundle install` to install all your new gems.

Once these gems are successfully installed, run the following command: `guard init`

The above command will create the file “Guardfile” in the root directory of your application. However, it’s an example Guardfile so we need to change it:


guard :rspec, cmd: 'spring rspec' do
watch(%r{^spec/.+_spec\.rb$})
watch(%r{^lib/(.+)\.rb$}) { |m| "spec/lib/#{m[1]}_spec.rb" }
watch('spec/spec_helper.rb') { "spec" }

# Rails example
watch(%r{^app/(.+)\.rb$}) { |m| "spec/#{m[1]}_spec.rb" }
watch(%r{^app/(.*)(\.erb|\.haml|\.slim)$}) { |m| "spec/#{m[1]}#{m[2]}_spec.rb" }
watch(%r{^app/controllers/(.+)_(controller)\.rb$}) { |m| ["spec/routing/#{m[1]}_routing_spec.rb", "spec/#{m[2]}s/#{m[1]}_#{m[2]}_spec.rb",            "spec/acceptance/#{m[1]}_spec.rb"] }
watch(%r{^spec/support/(.+)\.rb$}) { "spec" }
watch('config/routes.rb') { "spec/routing" }
watch('app/controllers/application_controller.rb') { "spec/controllers" }
watch('spec/rails_helper.rb') { "spec" }

# Capybara features specs
watch(%r{^app/views/(.+)/.*\.(erb|haml|slim)$}) { |m| "spec/features/#{m[1]}_spec.rb" }

# Turnip features and steps
watch(%r{^spec/acceptance/(.+)\.feature$})
watch(%r{^spec/acceptance/steps/(.+)_steps\.rb$}) { |m| Dir[File.join("**/#{m[1]}.feature")][0] || 'spec/acceptance' }
end

 

Now, when you run `bundle exec guard`, your specs will automatically run every time you edit your code.

When I’m working on a project, I generally like to keep a terminal window at the top of my computer screen so I can keep watch to make sure everything is passing correctly:

A picture of Guard