Category : Tools

Mark on UX

UX Principles for Mobile

Last weekend, I had the opportunity to give a presentation on  at the Designing and Developing for Mobile workshop put on by AngelHack. The event was attended by a spirited crowd of over 250 designers and developers, and included some insightful presentations from Janice Fraser, Founder & CEO of LUXr, and Aryeh Selekman, from Facebook.

UX is a great passion of mine and I’m excited by the new paradigm of designing continuity for products on multiple screen sizes. My presentation covered some tips & tricks for mobile design, analyzing mobile as a unique user experience, and how best to move forward in responsive design given the capabilities of the many devices for which we design.

I’ve embedded my slides below for anyone interested and will have the recorded screencast up shortly. Hope you enjoy! Feel free to leave a comment below or reach me at mlieberwitz@tagged.com if you have any questions!


Mark Lieberwitz is Mobile Product Manager at Tagged.

Python Interface to the HipChat JSON API

One of the many modern challenges to scaling a business is keeping employee accounts consistent. Traditionally, businesses would use a LDAP or Active Directory server and make all their tools plug in to those services. When someone was hired, they would receive a single user account that worked everywhere. At Tagged, we wrote a tool called SUMP: Simple User Management Portal. SUMP hooks into all the systems that we use, such as Google Apps for Businesses, our LDAP server and Hipchat, which we use for group chat.

There were already a few libraries available to access HipChat’s API but none had the user creation features we needed, and we preferred Python. So, we decided to roll our own library and release it as Open Source. Since many organizations have their own tool like SUMP, often written in Python, we figured this has a high value for other groups. Writing these libraries can be so simple that it’s easy for many people to create their own implementation. By releasing it as Open Source, we benefit because it pushes others to use the same HipChat API. This causes HipChat to maintain it for all their customers, and not just for us, so we don’t need to worry that SUMP might stop working one day. We also get the added benefit of possible outside contributors.

When we wrote this code, we decided to make it as Pythonic as possible. The HipChat API returned JSON objects, which are more like dictionary data types, but it was clear there were distinct data objects. Every API call gets wrapped into a typed class. Rather than building up JSON objects, function parameters are converted automatically so the library has a very object-oriented feel. Finally, there are some sample command line tools in the ‘commands.py’ file to demonstrate some common use cases for the package.

While the library is simple, it’s designed with a couple abstractions to make it extensible. Behind the scenes is a base class HipChatObject and a partially applied call_hipchat function for accessing any arbitrary API function. This makes it possible for other developers to add features to the library very rapidly when HipChat introduces new functionality.

The code is available on both GitHub and Gitorious and there have already been some pull requests over Gitorious. It’s just a small contribution, but along with other projects like the Node.js Memcached Library – we’re paving the way for Tagged to do even more Open Source contributions in the future.

Yaakov Nemoy is a Systems Administrator at Tagged and you can follow him on Twitter and on Google+.

Tech Talk: Design + UX

“Design you say? Pah, leave it to the designers! And leave me to my PHP and Node.js.”

Not so fast. As it turns out, the more you know about design, the more efficient you can be with your development work, leaving more time to focus on coding.

As Tagged’s Senior UI Designer, I want to remind you that even the most hardcore coders should think about design. Why? Because by considering a few practical design and UX practices, developers can create and code better products – while saving time typically spent backtracking with designers. Design and development actually share many principles in common, including: unified hierarchy, elegant simplicity, consistency and scalability/flexibility.

Each week at Tagged’s Development Workshops, we present best practices in product development. In this presentation, I discussed some essential design foundations for developers including:

  • Top-seven design principles for developers
  • Standardizing common elements with style guides
  • 960 grid system for layouts
  • The responsive Web, and designing for multiple-screen resolutions

Check out my video presentation and download the slides here. Got a design question? Leave a comment below or email me at ran@tagged.com.

A Preview of JHM

JHM is yet another build system. JHM understands not only how to compile code, but also how to run it, how to find tests for it, and how to check it for cleanliness. It is a general framework for building, testing, and packaging code.  You tell what you want, and it will do its best effort to build that for you.

We currently use JHM to compile our C++ codebase, and are working on converting older projects to utilize it. It presents a unified interface for building, testing, and packaging code which reduces the number of tools a programmer needs to know to get started on a project. In the rest of this post I will outline the goals behind JHM, and the machinery that makes it all work. We also plan on open-sourcing JHM.

Major Goals of JHM

  1. Programmers should not have to repeat themself.
    1. Programmers should have to write dependencies at most once.
    2. Compilation knowledge (ex. How do I compile C source to an object module) should be specified per-OS rather than per-project.
  2. Source code should not mingle with generated files
  3. Allow for rapid iteration
    1. Build should be fast, rebuilding after change should be faster.
    2. Running tests should be trivial, and possibly automatic.
  4. There should be a unified interface for compiling, testing, and checking code regardless of language.

How it works

JHM utilizes a large vocabulary to modularize the problem into well-defined pieces, which are then used by JHM’s core algorithms to build the code. The vocabulary makes the core pieces of JHM almost trivial.

Vocabulary

Each vocabulary term in JHM translates to a Python class in JHM. The term will be given, along with what it inherits from (indicated using the C++ ‘:’ convention), followed by a definition, brief explanation, and an example (if applicable). After that, there is a section listing attributes and functions of the class.

BuildableKind:

Describes the general form of a Buildable (which we will define next). A buildable kind knows how to extract or generate certain information for a buildable, such as the buildable’s run time dependencies (requires). For example, a buildable kind could know how to read a C++ source file and list the buildables it depends on. Other buildable kinds could know how to figure out what files need to be linked together to generate an output file.

GetRequires(Buildable): Examine the given buildable and return the set of buildables which are the run-time dependencies of the buildable.

GetRunner(Buildable): Return a function which, when called, will run the buildable. A build kind does not have to implement function.

Buildable:

Something which can be “built”.  All Buildables are interned, so that if the same buildable is asked for twice, both times the same object is returned. Buildable is an abstract class, and should not be instantiated.

availability: Whether or not the buildable could ever possibly exist. The function to discover whether or not a buildable is available, FindAvailability, is implemented by classes which inherit buildable

builder: A builder is a buildable which, when run, will create this buildable.

exists: Whether or not the buildable physically exists in the file system. This tells us whether or not the Buildable needs to have a builder to exist.

kind: An instance of BuildableKind

requires: A list of buildables which need to exist before the current buildable can be run. The list is constructed by calling kind.GetRequires. Note that as individual requires are built, the set of requires which are needed may change. This means that until all requires are finished, the full set is not known. type: The underlying type of the buildable, such as Job or Item.

Name:

A buildable within the environment, represented primarily as a relative filesystem path. The path can be constructed from something such as a Java or Haskell module name.

rel_path: The unique identity within the environment. This is a relative path within the environment.

branch: The directory within the tree where the name file resides; the portion of the path from the start of rel_path to the last slash.

name: The portion of the path after the last slash, the “filename” when you’re talking in general about file systems.

base: The portion of the name up to, but not including the last dot.

ext_list: The portion of the name after the last dot, split by ‘.’ and represented as a list. Note that the list always has length greater than or equal to one. An empty extension is valid within the extension list (Such an extension is given to Linux executables).

prefix: The portion of the base which is always the same for a name of the same Kind. For example, static libraries always start with ‘lib’. This is often an empty string.

atom: The portion of the base after the prefix. This is the kernel of the file’s identity and the portion of the name which is shared between different but related names.

kind: The buildable kind. Normally this is derived from the last extension in the extension list, although it may be manually specified at name construction time.

Overall:
   <rel_path> -> <branch> <name>
    <name> -> <base> <ext_list>
    <base> -> <prefix> <atom>
Example:
   rel_path = ‘/there/everwhere/libthorium.a’
    branch   = ‘/there/everywhere’
    name     = ‘libthorium.a’
    base     = ‘libthorium’
    ext_list = [‘a’]
    prefix   = ‘lib’
    atom     = ‘thorium’

Repository:

A location where JHM will look to try and turn a name into an absolute path. A repository could be a directory, a language specific module repository (Python PyPI, Ruby Gem, Haskell Hackage, etc.), another JHM project, or a collection of JHM projects.

Contains(Item): Returns whether or not the given item is contained within the repository.

Item: Buildable

A name which has been tied to a repository. Names can only ever be associated with a single repository. Items are interned on their name.

name: The instance of Name which the buildable represents

repo: The repository which the item resides

Job: Buildable.Item

A manipulation, transformation, and/or generator which can be run to create one or more Items. Jobs are interned on each individual output they produce. A job could be linking .o_pic (object files compiled with –fPIC) files together to build a static library, such as libthorium.a.

GetRequires(): Examines at the output of the job and determines what the job will need in order to create the desired intput. For example, seeing libthorium.a comes from thorium.cc then finding the .o_pic files needed based on thorium.cc includes.

output_set: The set of buildables the job will produce when it is run.

Environment:

JHM needs a complete worldview of your project and its dependencies in order to operate. This world view is stored in the JHM Environment (Env). An environment contains a collection of Config files, Repositories, Jobs, and Items. It is the level at which Buildables are interned. The heart of the environment is the project root. The project root is a directory which is auto-discovered by locating the nearest parent folder containing a folder named .jhm (this folder contains the JHM configuration). The project root must have the source directory as a subfolder, although it may be arbitrarily nested. The output directory should be inside the project root as well, but that is not required. Generally speaking, the folders are laid out like so:

$(project root)/
      .jhm/
      $(source_dir)/
      $(out_dir)/

Algorithms

JHM being written in python, the algorithms below are written in python-like pseudocode.

Finding item availability

Producing Producables
Moving Forward
As we work to convert more projects to utilize JHM, we continue to make improvements to it and develop new features within it. The current version of JHM used in development is Tagged is available on Github at https://github.com/tagged/jhm. If you’re interested in keeping up with the Tagged team, be sure to follow us on Github and/or Twitter.

Cody Maloney was a software engineering intern this summer as part of the Stig team.

hackathon logo summer 2011

Tagged’s 2nd Hackathon: Summer Edition

A few weeks back, Tagged kicked off its second overnight Hackathon, complete with caffeinated beverages and a midnight In-N-Out Burger delivery. Our Hackathon invites anyone and everyone from Tagged to tap his or her inner hacker to build an overnight project that is exciting, useful or just plain fun. Having more than doubled our staff and office space since our last hackathon, there was major buildup for this event so we couldn’t wait to see what our teams would come up with.

The Tagged Hackathon started at 6 p.m., right after our usual dinner was served. Everyone ran down and gathered into our new (and expanded) office meeting room to pitch their ideas and recruit a team. More than 20 different projects were formed, and off the teams went to begin spec’ing and coding.


There was a range of projects, which included:

  • SimpleQL, creating an easy-to-use SQL query generator
  • A drawing board for our Tagged mobile app
  • Two-Factor Authentication, offering a way to completely secure access to an account
  • Tagged Connections, a visualization of friend connections occurring around the world

At midnight, In-N-Out Burger was rolled in and served for all.

The energy continued well beyond our midnight snack with every team aiming to create a working prototype by morning. For those that made it through the night, breakfast burritos, fruit, and other healthy breakfast items rolled in at 6 a.m. Special Tagged Hackathon t-shirts were also given along with permission to leave work for the day.

A week later, the entire company voted on winners in three categories: Product Innovation , Overall Awesomeness, Technological Achievement. In product innovation, “Awesome Pet Run” won as a new way for players to play on of our most popular games Pets. Overall awesomeness was awarded to “Clickable Interests/Orbits”, which created a new way for discovering users via common interests and made search results more dynamic and interactive to encourage new connections via ‘Orbits’. The Technological achievement award was won by our Director of Engineer, Diego Matute. Diego explains the project below:

One important theme with our users is that they care about their account and have a lot invested; both emotionally and economically. The two-factor authentication project highlighted a very secure and easy way for users to protect their accounts from phishing, keyboard logging and spoofing. Instead of entering an email/password combo, the user proves two things: 1/ have something (their phone), 2/ know something (their pin). It works a lot like a debit card at an ATM. Secureness is achieved by using OAuth as the user/service provider protocol and an iPhone app to securely store tokens. A simple enrollment process also makes it easy for users to opt into this feature and benefit immediately from secure access.

We witnessed some stellar Hackathon results and were blown away by the creativity of our participants. We’re excited to implement many of the projects into Tagged!

Check out our Hackathon video too: