General Archives - Page 19 of 26 - {5} Setfive

Over the weekend, Fred Wilson posted an awesome video of the unboxing and flight of a Parrot AR drone along with a note that he was planning to grab one and develop some custom node.js code for it. After seeing the video, and with spring finally here I started brainstorming about what gadgets I’d want to play with over the summer.

Parrot AR Drone

Shown in the video linked above, the Parrot AR Drone is a remote controlled 4 rotor helicopter that is controlled via an iOS or Android device. What sets the Parrot apart from other similar devices is that it there is an node.js library for simplifying development of custom functionality on the Parrot platform.

Not exactly sure what we’d be looking to build with an AR drone but the Red Bull Air Race comes to mind.

Sphero Robotic Ball

Built by Boulder, CO based Orbotix the Sphero robotic ball is a gyroscopically stabilized ball that can be controlled using an iOS or Android device. The Sphero has a software development SDK and there’s also an active app store to download pre-built apps that work with your Sphereo.

Just brainstorming, but something awesome to build with a Sphero would be an app to draw out large drawings using the Sphero to actually draw the lines. Imagine drawing a 50’x50′ line art graphic by uploading some art and then letting the Sphero roll around the canvas.

Pebble watch

Born on Kickstarter, the Pebble watch is an indie entrant into the “smartwatch” space. Sporting iOS and Android integration via Bluetooth along with a scriptable watch face, the Pebble is shaping up to be an interesting player in a developing market.

As far as development, writing custom faces to visualize information differently or pull data off a smartphone seems to be pretty exciting. It still seems a bit early to get a sense of how the Pebble will fare long term as a platform though.

Jawbone UP

Although primarily known for their speaker systems and Bluetooth headsets, the Jawbowne UP is a personal activity monitor that helps users track their physical activity, sleep cycles, and eating habits. The UP fits into the trending theme of the quantified self, where users track KPIs about their daily life in an effort to iterate and improve. Pulling data off the UP is relatively easy and it also plugins in to RunKeeper.

The “quantified self” concept sounds like it would be interesting to experiment with and using the UP to try it out seems like an obvious choice. Leveraging the UP would also make it easy to “compete” with anyone else looking to jump into activity tracking.

Raspberry Pi

Released last year after intense anticipation, the Raspberry Pi is basically a six square inch board with a fully featured computer including video output and USB ports. Coming in at $25 or $35, the Raspberry Pi is cheap enough to experiment with, hack it, and if it happens break it. With full Linux support, the Raspberry Pi is also robust enough to handle “serious business”.

Looking at the list of Rasberry Pi Hacks, theres definetely some awesome inspiration to build something cool. Using a Pi to power a TV screen with real time interactive content seems like it might be an early winner though – we’ll see where that goes.

Anyway, that’s my list, unfortunately I’m not sure what I’ll actually get around to hacking on this summer. Would love to hear about any other cool gadgets or hacks.

Last week, I was putting together a Google Chrome extension for one of our clients to help debug Javascript events on a page and I started wondering why don’t we have mobile browser extensions? Unfortunately, there isn’t a simple answer but I think looking towards the desktop can help draw analogies to where we are on mobile now.

So this desktop thing?

Looking back to the desktop, arguably one of the strongest drivers of Firefox’s growth was its rich extension ecosystem. Compared to Internet Explorer, Firefox extensions were easier to develop, leveraged web technologies (XUL, JS, CSS), and offered powerful abstractions out of the box. Because of this, developers began building powerful extensions for Firefox which drove “power user” adoption and ultimately helped spur mainstream adoption. Developers built extensions like Firebug, Greasemonkey, and companies like Rapportive inside the Firefox extension ecosystem. Following Firefox, when Google Chrome launched it debuted its own even simpler extension infrastructure and eventually the Chrome Webstore to help distribute and monetize extensions.

Although largely positive, the extensions developed for Firefox and Chrome weren’t always user friendly. Between redirecting search traffic and surreptitiously injecting ads, “greyhat” extensions negatively impacted user experience while generating revenue without generating value. These “greyhat” extensions fueled what’s colloquially known as Israel’s download valley and ultimately millions of dollars in revenue.

Right so what about mobile?

Compared to the desktop, the landscape on mobile is notably different because of an Apple and Google duopoly with Apple primarily monetizing hardware and Google monetizing search advertising. Additionally, compared to the desktop, Apple and Google have an unprecedented level of control over user devices, all but ensuring that devices will arrive with either Safari or Chrome installed.

I think because of this control, Apple and Google have little incentive to open up Mobile Safari or Mobile Chrome to 3rd party extension developers since doing so would compromise the browser user experience for little gain over the competition. But what about Firefox?

Although Mozilla has released a Firefox build for Android, I think they’ve recognized that trying to win market share away from Chrome on Android is a losing battle and they’re starting to seriously pursue FirefoxOS. Because of this, I don’t think Mozilla will invest in Firefox mobile extensions since it’s clear that there’s more opportunity in powering the OS layer of a user’s phone.

Monday was a horrific day in Boston and its been an uneasy day after. I don’t have anything to add to the discourse but I would like to urge you to join us, along with the technology community in supporting the victims.

TUGG has setup a fundraise.com page here – https://www.fundraise.com/technology-supports-victims-of-boston-marathon-bombing and over $100,000 has already been raised.

In 2009, an engineer using the pseudonym Satoshi Nakamoto introduced a new digital, open source, currency to the world called “Bitcoin”. Since then, the buzz, excitement, and adoption of bitcoins has grown at a phenomenal rate, with the total value of bitcoins in circulation hitting $1 billion as of April 2013. Talk of a bubble has coincided with the buzz, but both have also served to highlight the tremendous potential in the Bitcoin ecosystem.

Great, so what is it really?

Paraphrasing from Wikipedia:

Bitcoin is a decentralized digital currency based on an open-source, peer-to-peer internet protocol. […] Bitcoins can be exchanged through a computer or smartphone locally or internationally without an intermediate financial institution. […]

Bitcoin is not managed like typical currencies: it has no central bank or central organization. Instead, it relies on an Internet-based peer-to-peer network. The money supply is automated and given to servers or “bitcoin miners” that confirm bitcoin transactions as they add them to a decentralized and archived transaction log approximately every 10 minutes.

I’m going to butcher any explanation I try to provide but Quora has several good writeups on what Bitcoins are and how they work. A reasonable analogy though, is think about “Bitcoins” as a type of precious metal that has no intrinsic value but is able to store value, transfer value between parties, and be mined to find new pieces.

The key takeaways about how Bitcoins work are:

Unlike traditional currencies, no central bank controls the amount of currency in circulation. Instead, the total amount of possible Bitcoins is algorithmically limited by the protocol itself.
Transactions between parties are relatively anonymous and done in real time. Contrast this with other digital payments like credit cards or wire transfers where there is little anonymity and a settling period.
As of now, there’s absolutely no regulation as far as reporting, security, or anything else you’d associate with traditional financial institutions.
Currently, it’s all digital – there’s no practical way to “print” a Bitcoin and use it like a dollar bill

So what’s going to be disruptive?

There are dozens if not hundreds of startups playing in the Bitcoin space and several “large” companies have also started adopting Bitcoins as an alternative form of payment. Several high profile investors including YCombinator and Union Square Ventures have also made significant Bitcoin related invetments, signalling that savvy investors believe a potential market exists. Personally, I’m excited about companies attacking the following:

Hassle free, instant, and international money transfer. Paypal was supposed to allow us to do this, but even in 2013 its difficult and expensive to transfer people money – let alone internationally. If someone can address the current concerns of fraud and money laundering using Bitcoin they’ll have an instant winner on their hands.

Catapult in legalized online gambling. In the last few years, there’s been an ongoing discussion about if America should legalize online gambling and if so, how it should be done. Because of the decentralized, anonymous nature of Bitcoin, it’s conceivable that the emergence of a large enough Bitcoin powered gambling market would force the US government to legalize online gambling in order to get access to the additional tax revenues. This would obviously be a boon for struggling social game companies like Zynga, but also provide an enormous opportunity for new startups.

Provide a viable alternative to credit cards. Recently, there’s been a lot of action in the payments space including innovative companies like Square and Roam which are aiming to alter how consumers pay at the point of sale. Unfortunately, almost all of these new payment solutions still rely on existing credit card infrastructure to complete the payment which leaves them at the whim of interchange fees. Boston based LevelUp is tackling this issue but at the end of the day they’re still getting hit by the fees somewhere. An innovative Bitcoin company which provides a viable alternative to this existing credit card infrastructure would open the door to radical innovation in the payments space by eliminating hard interchange fees.

What might go wrong?

There’s a huge amount of opportunity in the Bitcoin space and the ecosystem is just starting to build out. With the Bitcoin boom of 2012 already inked on the Wikipedia entry, the next few months are going to be a critical time for the nascent currency. The single largest to Bitcoin is ultimately going to be regulation from sovereign governments. The US Department of Treasury has already issued several statements regarding Bitcoin and its clear the government isn’t happy with the situation as it stands now.

Regardless of what regulation is passed, Bitcoins are technologically different from previous virtual currency and the ecosystem has already demonstrated its resilience and innovation.

One of the hardest things to do when building a software product is effectively communicating your ideas to your development team. In addition, these issues are usually magnified when you’re early on in your product process. Generally, communication issues between stakeholders and developers fall into “macro details”. “expected behavior”, or “user interface concerns”.

Despite being an oxymoron, “macro details” captures the types of errors that occur at the architecture level. For example, imagine you were building a calendaring system for intramural sports teams where each team manages their games for the season using the calendar. A “macro detail” would be that each “team” owns a single “calendar”, a potential error then would be the development team coming back with a solution where every “player” on a “team” owns a “calendar”. Following from that, the “expected behaviors” of the system would capture issues like “what happens if two teams try to schedule a game for the same day?” or “can a player be on more than one team?”. A defect then would be that the stakeholders expected the system to not allow multiple games on the same day but the system allowed it. Finally, “user interface” concerns would typically encompass how the various components of the application are organized and what the different screens are.

Great, so how do you avoid these problems? What follows below is a loose framework for mitigating these issues, it certainly isn’t original but rather a synthesis of techniques that I’ve seen help power effective communication.

Oh hey, from 10,000 ft.

For a totally new product, getting started is often the hardest part. Usually, the entrepreneur or executive who is building the product has been frantically planning, talking about, and “living” the product for sometime before the project actually kicks off. The result of this, is that the stakeholder intimately knows the ins and outs of the project but the rest of the team won’t necessarily be aligned with the primary stakeholder. Because of this, starting by writing a 1 – 2 sentence “10,000 ft. view” is usually a great first step. Using the sports calendering example from above, you might end up with:

I want to build a calendaring application to allow intramural (think old man kickball) sports teams to collaboratively plan their games for the season.

Who, What, Where?

With the “big idea” down on paper, the next step is to start defining the primary objects in the system and how they are all related. At this stage, other people normally develop “user personas”, which describe typical users of the system, and then elaborate on how each persona will use the system. In my experience, this approach is effective but inexperienced stakeholders tend to get caught up in the details and ultimately have a difficult time reaching the right level of abstraction. Looking at the calendaring app, some of the objects you’d end up listing would include:

Teams
- Composed of players
- Own a single calendar
- Linked to a single league
Players
- Primary actor in the system
- Each user will be represented by a player and own a single profile
- Linked to a single team
Calendars
- Owned by a single team
- Contain games on specific days
Leagues
- Comprised of multiple teams

Anyone that is familiar with Unified Modeling Language will notice the format is similar to how UML uses nouns and verbs but its a bit different. I’ve always had better luck using natural language to write out the relationships between entities and then converting that into an entity relationship model and then RDMS tables.

Rules, Rules, Rules

Once the primary entities are defined, the next step is to write out the business logic to minimize the confusion around how the system should work. There are formal structures for this as well, including behavior driven development, but in my experience its easier to kickstart the conversation with natural language specifications and then introduce BDD later in the development cycle. Anyway, running with the example you’d end up writing out something like:

Users (Players)
- Can create accounts
- Can create games on a calendar
- Can join “Teams”
- Can’t join two Teams
Teams
- Created by “Players”
- Can’t be deleted after there’s at one member
Calendars
- Automatically created when a team is created
- Won’t allow two games on the same day
- Can’t be deleted
- Will only allow users to edit their own events/games

Like with the entity relationships, I usually start with natural language and keep the definition of “business logic” pretty loose so that I can capture as much information with the stakeholder as possible and then formalize from there.

Draw me a map

Finally, the last piece is usually communicating what the UI of the application should be. Depending on the makeup of the team, the amount of input that business stakeholders have in this respect might be minimal. However, if there isn’t a dedicated UI/UX resource available UI mockups will definitely be a valuable asset in helping communicate the vision of the application.

There’s several tools for developing UI mockups including Balsamiq, OmniGraffle and Mockflow. Generally, any tool you’re comfortable with will work fine but the key concern should be not “lowering” the designs too far to allow people to concentrate on the ideas, not the specific implementation. I’ve always been partial to Balsamiq since its attractively priced, easy to use, and the final mockups are more like sketches than a finished design.

Anyway, sticking with the calendaring project you might end up making a screen that looks like this:

Like everything else, the definition of UI mockups are generally flexible. Some people like to “lower” pretty fair to high fidelity designs and other people like to leave them at “pen and paper” type sketches. At the end of the day, it’ll be a project by project decision.

Wrapping up

Well thats a crash course, with examples, of how I generally work with key stakeholders to sketch out projects. Ultimately, figuring out the best way to communicate your vision to your engineering team is going to be a personal decision. You’ll probably end up having to mix together several techniques that take advantage of the skills on your team and match the requirements of your project.

Category: General

Gadgets: 5 gadgets for your summer wishlist