I’ve been trying out Medium over the past few months as a place to share thoughts, and have been enjoying the experience. Check it out for my most recent posts. The latest includes:
A Product Launch To Be Proud Of
Building an Effective Technical Interview Process
Head on over there to check out these posts, and follow me to stay up to speed with what’s going on in the future. Only time will tell whether I return here to my WordPress site.
I very frequently get asked, “What is Wildcard?” People want to know what we’re building. It’s an extremely fair question, and it is one that we should be able to answer without hesitancy. Other variations include:
What is your vision?
What is true North? What is the bullseye of the target you’re running at?
What if you ignored all outside influences, and just built the thing you wanted to build? What would it be?
While there are many sides of our business, and it would be easy to begin describing the B2B opportunities in mobile or the SDK opportunity to serve other apps, what people are really curious about is the consumer vision for our product. In my head, I have a clear view of what I believe we are executing towards on the consumer facing side. I have a clear view of the future of the Wildcard app. Yet still, it’s been difficult to convey it to people concisely. It’s been even tougher to distill it down to one easily understandable sentence. This essay attempts to make clear exactly what it is that Wildcard is running at.
So, what are we building? The browser for the native mobile internet.
That’s it. The tagline may not be consumer friendly, and it may not be marketable, but it’s the most straightforward and honest description of what we are trying to accomplish. The unfortunate part of this seven word description is that it opens up many sensical follow up questions in order to truly understand what it means; for someone who hasn’t thought deeply about the future of the internet on mobile, and isn’t familiar with many of the new cutting edge technology decisions that big platforms are making, there is a lot of required background information in order to accept this as something both possible and necessary. Let me try to begin addressing some of the biggest questions.
What is the native mobile internet? In many ways it is similar to the current world wide web. It is an open network of machines serving data in response to requests, and users view and interact with that data from their client – a browser. However in the native mobile internet, these servers don’t serve pages, markup, or styling information along with their content. They just serve structured data according to a schema. And they just respond to actions according to a well defined interface.
The reason there is no HTML, CSS, or javascript-based flexibility to manipulate the layouts or provide custom actions is based on the idea that on mobile there are so many different screen sizes, form factors, and “edges” emerging (like Apple Watch or Android Wear), that from the perspective of a developer it’s nearly impossible to deliver a great experience across all these devices. Instead, if the developer or publisher delivers structured data according to a schema, then it can be up to a client implementation on each platform what the best possible native experience for interacting with that content is. On Watch it may look a lot different than on iPhone, and that’s ok. Every developer everywhere doesn’t have to decide what the killer experience is – they just need to provide their content and functionality, and the platform will handle providing the best experience.
This idea sounds reasonable in theory, but it would be logical to wonder: is it even close to remotely possible that developers and publishers would structure their data such that it can be rendered in a way that they don’t control? This is already happening. Publishers already structure the data behind almost every popular web page into schematized standards. OpenGraph, Twitter Card Markup, Schema.org, Microformats, are all examples of publishers providing this structure. And the platforms that consume them and render them natively, FB, Twitter, Google, and Pinterest, already use this structured data to alter the experience and place their content in areas that the publishers don’t control. On mobile this tradeoff is even more important, as the experience of leaving one of those platforms to consume publisher content in the web is terrible, whereas consuming it inline is far more natural and engaging for the user.
Of course, there is still a long way to go before this loose collection of markup standards become the backbone of a true native internet that exists devoid of web pages in the first place. In addition to structuring content, publishers need to respond to actions like “search”, “signup”, “buy”, “locate”, etc. Defining these supported actions, and defining the different structured data elements that are supported on the native mobile internet, is part of Wildcard’s charter, hopefully with the participation of the major platforms and other interested parties.
Moving on to other questions that need to be addressed, What are cards? Cards are the UI element that Wildcard uses to display the structured data and interactions natively on iOS. And we believe that they work well on Android, watches, glass, and other mobile and desktop platforms. It’s possible that we’ll need other UI elements for other edges that emerge, like voice interfaces for example, and that’s fine. The native mobile internet supports rendering the content in whatever way the platform implementor (browser provider) sees fit. “Card” is just a word…don’t get too hung up on it. However, cards do have a couple properties that make them appealing when searching for something that’s cross platform – they’re self contained, they’re portable, they can link to other cards, they’re simple. It’s easier to do a platform implementation of a card type when you know it’s size, shape, and data elements, than it is to do an open ended one for content of any size, shape, color, and level of interaction.
At this point you should hopefully realize that some of the building blocks of a native mobile internet have already emerged. Data is being structured by publishers, and displayed natively by platforms. Wildcard’s consumer opportunity is to build the first browser for this native mobile internet. And part of its thesis is that users will prefer this browser because it will be faster, more consistent, and less prone to failure or dissappointment or frustration than conventional web based browsers on mobile. Because it’s based in structured data and actions, and the content is rendered natively in the best possible way, the user experience will be “guaranteed”. This is very different from the roulette users play on mobile when clicking on google search links.
If Wildcard built only on top of what existed today, the best it could really do would be to display static content in the form of cards, and on top of that it could build a way for users to find the content they’re looking for. However, much like Netscape in the early days of the web, as part of building the first browser we also have to define some of the building blocks of the native mobile internet as we go. Some of these building blocks include answering questions around how cards link to other cards, how publishers receive input or personalization, how you build applications on top of these primitives, how publishers monetize their content, how identity and payment are baked natively into the browser, how publishers differentiate their brand’s presence, and more. The vision for Wildcard takes note that these questions need to be answered and aren’t figured out just yet, but running at finding the right answers to these questions should be part of the thrill of working with Wildcard. People with strong opinions rooted in experience should be eager to make the right calls here, with the mobile user in mind.
Finally, I’d like to loop this back to where Wildcard is currently. For 2015, we are working on two major product themes: search experience and home screen experience. Why focus on search if you’re building a browser? As Google has demonstrated on the desktop web, search is the killer application. It allows users to express their intent, and quickly find the content or actions that they’re looking for. As the native mobile internet emerges, there’s an opportunity to build a powerful native-only search. The cards that exist and the functionality that’s available is different than what exists on desktop. In addition to this being the huge long term opportunity, it also improves the user experience in the short term. A browser without access to search may not be compelling enough for consumers. In direct support of this search effort, we’re working on a data project to know about every piece of structured content out there, such that it’s possible for us to search, find, and surface this content to users in the browser.
And on the other hand, the home screen focus aims at making the browser compelling for users in the absence of an amazing search experience. The reasons for this are threefold. 1) Search is difficult and may not be good enough for awhile. 2) Initially search may not be a daily behavior on mobile, like reading top news or following socially shared content. 3) Many new users like to browse and discover, rather than explicitly declare their intent. Think of the Wildcard home screen as an attempt at creating the best home screen on the internet, analogous to Yahoo.com, AOL.com, or MSN.com. Sure, power users may start at Google or in a blank tab, but those home screens still serve as the starting points for much of the traffic on the internet today. As the native mobile internet emerges, many other home screens will be possible, including ones based purely on search, purely on navigation, purely on bookmarks, or purely on personalization. Today there may only be one starting point, but in the future, much like within a web browser, the user can start wherever suits them best.
In summary, Wildcard is a browser for the native mobile internet. This browser makes it possible to browse all the “cards” or structured pieces of data out there today, and in the future. It has the best home screen for navigating to and discovering these card experiences, and it has the best search engine for satisfying user intent within these experiences. It may take awhile to deliver on all of the above, but trends are all moving in this direction, and we have an incredible early team to continue tackling these challenges.
* If you’d like to join us on this mission, email me at any time.
About a year and a half ago, my co-founders Jordan, Eric, and I set out to try and make the internet easier to use on our phones. We felt that interacting with slow, clunky web pages in Safari, that required you to pinch to zoom in and out, pan around, and type lots of information into awkward forms was a really poor way to access the amazing internet that we’ve been accustomed to using over the past 20 years on our desktop and laptop computers.
At the time, we didn’t know exactly how we were going to solve the problem, but we knew that a better way to consume content and take action on mobile must be possible. We started looking at the app ecosystems and the mobile web ecosystems, and found the benefits and drawbacks of each. We began to formulate a hypothesis that on mobile you are really looking for a fast, simple, app-like experience with the benefits of the web, like searchability, sharability, discovery, and URL-based permanence. At the same time we saw trends emerging within the big platforms like Twitter, Pinterest, Google, and Facebook where those services would pull the content behind URLs into rich, user friendly cards on mobile, so users would not have to click through to the web. We were experimenting with very similar concepts, and arriving at very similar conclusions. This was a trend that we wanted to build product around.
Fast forward to the current day. We’ve been fortunate to have an amazing group of believers join our team to work on all the hard engineering, product design, and business challenges that need to be overcome to convert the existing legacy internet into a new native, card-based internet. Two weeks ago, we launched the first version of Wildcard – the world’s first “card browser” – which contains search, navigation, and display and interaction for native mobile-friendly cards. That’s a highly technical mouthful, so to simplify – Wildcard is a faster, easier way to use the internet on your phone. We’d like to replace your web browser, but we are not a web browser. In Wildcard you can’t access every page on the legacy internet using a URL, and when you search you don’t get ten blue links back that you have to click on to go to a web page. Instead we’re a browser for a smaller, mobile friendly internet – an internet that’s still being defined and built. We work a little differently, but when we succeed, you know that you’ll be getting a fast, clean interaction.
I believe that our domain name, trywildcard.com, is fitting because what I really would like to ask of people today is to “please try Wildcard.” Replacing your web browser is a monumental task – one I believe that we can accomplish over years of hard work, with lots of participation from developers, partners, and the community – but we are by no means a total replacement for your web browser today. Instead, I believe that Wildcard is the beginning of a much better experience for interacting with a new type of native internet on mobile. Today it performs very well for some tasks – reading news and articles, shopping, watching videos, looking up facts, staying on top of what is new and interesting in the tech world. Try Wildcard when you take out your phone and intend to do one of these things. The next time you’re about to open Safari and run a search, please give Wildcard a try first. We won’t yet nail every experience, but when we do, I believe you’ll have a better, faster, experience than you would using the legacy web. And our team is working hard to add new cards types, add better search support for more types of queries, and add new content so that two weeks, two months, and two years from now Wildcard moves closer and closer to being your preferred way of using the internet on your phone.
In my role as VP Engineering at Wildcard, I’m most excited about the technology that we’ve been building to power all of the card interactions you see in Wildcard with the existing web sites on the legacy internet. In the future we may live in a world where everyone is publishing and serving their own cards, but in the meantime we need to use our tech to bootstrap this new internet, and we’re facing tremendous challenges around crawling, classification, data extraction, search, emulation, proxying, error detection, performance optimization, mobile development, internal tooling, and more. I’ll write more about our technology in future posts. For now, please check out the product, download Wildcard from the iOS app store, and let me know what you think.
This past week at Wildcard we decided to run a programming challenge. The contest, targeted at developers, consisted of two easy-to-medium difficulty programming problems that were designed to take anywhere from 30 minutes to a couple of hours to complete. Anyone who completed the challenge was entered into a raffle where we gave away a couple of fun prizes. The three winners of the challenge are:
1 Bitcoin – Douwe Gelling – a PhD student at The University of Sheffield
1 Year Dropbox Pro Account – Christophe Biocca – Founder at Encircle
1 Year Github Small Account – David Sinsky – NYC Based Software Developer & Entrepreneur
Overall the challenge was a huge success. We spend time building and releasing these challenges because it’s fun, a great way to meet and interact with the engineering community around the world, and a great way to raise awareness around Wildcard. A few thousand people viewed the challenge, a few hundred got through the first problem, and about a hundred people successfully completed it. The challenge is timed, so that anyone who wants to race through it can see their time at the end, but it is not a race. It’s meant to be fun, and invoke some thoughtful remembrances of algorithms class back in college.
There were submissions in just about every common programming language: Java, C++, Ruby, Python, Haskell, Go, Ocaml, Scala, Javascript, Bash, Excel, Paper + Pencil, and more. A casual observation would lead me to conclude that in general Python and Haskell programmers submitted the most concise solutions, while Ruby and Java programmers submitted the most readable and object oriented approaches. Python was the most commonly used language.
I won’t give away spoilers for how to solve the problems considering many people still want to take the challenge, however I will share a few notes about constructing the problems and solutions. In general the first problem was fairly straightforward, involved some basic mathematical insight, and involved a couple different programming concepts like parsing an input file, constructing the data in a data structure, and calculating the solution. Most people that got tripped up on it failed to make the mathematical leap but quickly got there with a hint.
The second problem had a less efficient brute force solution and a more efficient solution that many people eventually arrived at. It involved less programming that the first problem but more algorithmic thinking. The weakness of the second problem is that the range of potential answers was small, so many people brute forced the guess and then worked backwards to figure out how to arrive at the answer. If I could rewrite this problem I may have made the potential answer range an order of magnitude larger to avoid guessing. However the reward for the challenge is definitely in the journey, and not in the answer. Cheers to everyone who solved both problems and made it through!
While there are no longer any prizes, the challenge is still up and running, so feel free to give it a try. And as always, if you’re interested in an atmosphere where puzzles, programming, and solid engineering comes first and foremost, please reach out and get in touch with us about Wildcard. We’re hiring.
Every time I’ve started to work on a new project I’ve been fortunate enough to have the opportunity to learn a whole new set of technical skills. At Frogmetrics it was Python, Pygame, Maemo Linux, and the world of early stage mobile performance constraints. In the early days of JumpPost and Hyperpublic it was web development – Ruby, Rails, Javascript, server administration. As Hyperpublic’s data platform grew and we moved on to join Groupon it was higher performance/scale data processing tools like Storm, the Java ecosystem, and a variety of databases and data processing techniques. And this time around, as we’ve been getting started on Wildcard, I’ve picked up iOS development, in order to tackle the problem of creating the fastest way to interact with the internet on your phone.
So far it’s been good times. Apple has created a great platform that makes it possible for developers to create beautiful, fast, polished applications that live up to the promise and expectations created by all of the great apps you interact with every day. However, getting up to speed, getting comfortable, and getting confident with iOS development has definitely been a different process and different challenge than getting up to speed on some of the other mobile, data, and web challenges that I’ve tackled in the past – in particular, the process has been more isolating than usual.
Why is learning iOS development more isolating than web, api, or data processing based development? Because it is just as much an art as it is a science, and as many artists will attest – the creativity must come from within.
When you’re trying to learn science you can surround yourself by the reference material of a previous generation of scientists – in this case books, stack overflow posts, IRC channels, github repositories. The actions that you’re trying to take when you build a web application are largely mechanical. You read in a request, interpret it, load data from a database, and plug it into your response. The interesting code you write is your business logic, and you let the framework handle the rest. You can always piece this together via all the available reference material, and if you’re confused as to whether you’re doing it “the right way”, you can always fall back to your basic knowledge of the internet and databases (HTML, CSS, SQL). Failing to understand all of Rails doesn’t mean that you’ll fail to produce a web application that does what you need it to.
But when you’re trying to learn an art form, equal parts design, user experience, and engineering – and the bar for an impressive user experience is set really high – there’s nothing to fall back on. Implementing the business logic is still a requirement that should be fairly straightforward, but creating beautiful UI, custom controls and actions, transitions, and animations are not something you can follow directly from a blog post or stack overflow thread. Programmatically creating and keeping the UI up to date based on a series of gestures, user actions, and external notifications within the rules and frameworks that Apple has made available is not something you got experience with doing anything else. There are a series of great meetups, events, and a bulk of material available online and in print to try and teach you the basics, but when it comes down to implementing the experience that you want for your users, the reference material won’t help. You and your team are on your own.
That’s why I believe that a more effective way to learn iOS development is the mentor-mentee relationship. The ideal pairing is a developer with good fundamentals and a confidence that they’ll be able to pick up the basics of any technology, working closely with someone who’s gone through the trials and tribulations of learning the nitty gritty details, design patterns, various techniques for impacting the “art form” of iPhone development. I think pair programming is always a good idea when reasonable, however in an early stage startup it’s not always possible due to limited resources and developers needing to split responsibilities across skill-sets. However in the case of iOS development, I believe that as much pair development as feasible in the early days is the most efficient way to learn.
Now that I’ve gone through the struggles of getting myself up to speed over the past few months, I’d love to bring on an aspiring entrepreneurial engineer to work closely with me to own mobile product development at Wildcard. If you believe in our vision, and you see yourself as someone who wants to learn mobile development, and one day start your own tech company, then I believe this is a great place to learn. Please get in touch.
Today was a fun day, as we finally put a name and public face on our new startup – Wildcard. For the past 5 months we’ve been working without a real name, without a public facing site, and without really announcing to the world what we’ve been up to. While it’s necessary in the early days to spend time thinking internally, figuring out exactly what your mission is and how to communicate it, there comes a time when you need to step out into the world.
So what are we working on? My co-founder, Jordan, describes it really well in his blog post…
We are building the definitive card platform for the mobile web. Every site in the world, every action you want to take, all the things that are hard to do on your phone but easy on the desktop web…they can and will live inside of cards…and we are building that reality.
We’re designing the easiest and most intuitive way for users to find mobile cards on their phone. Every brand on earth, actionable in a consistent form. All of the power and breadth of the legacy web, with the simplicity and functionality of concise native apps.
I suggest you read his entire post to get the full context of why this is necessary right now. But hopefully, if you’ve ever felt the pain of trying to take action on the mobile web – to buy a pair of sneakers, or look up the amtrak schedule from Philadelphia to New York, or book a flight, or make a dinner reservation – then you realize that there must be a better way. We believe that interactive cards are the better way, and we’ve been working hard on building a platform that will solve this major pain point for consumers.
And we need help. I’m looking for smart, inspiring, entrepreneurial engineers to join us as we work to create this platform and change the way people use the internet on their phones. Here’s a sampling of the problems that we’re working on…
There will be room to focus on all of these areas as we grow over the next year, so whether you are an experienced engineer looking to lead one of these efforts, or a recent college CS grad looking for their first job, I want to talk to you if you’re interested in this problem. I really value the entrepreneurial spirit and drive, and generally hire employees who want to go on to start their own startup in a few years. Wildcard is a great place to learn and observe the ride from the beginning.
Check out our job postings and feel free to reach out to me anytime at doug@trywildcard.com.
I was talking with a smart dude yesterday who told me that people are very lazy when it comes to choosing what tool to use to accomplish a given task. They’ll generally opt to use what they’re comfortable with, and what’s immediately available to them, rather than using just a little bit of extra effort to find the more reasonable tool for the job.
In the case of iOS this manifests itself in users choosing to use the app that is sitting on their homescreen instead of scrolling to a separate screen, opening a folder, and choosing the app that will make their life easier. And going one step further than the homescreen, you would assume that users would be obsessive about what apps they give space to on their dock – the four apps that sit anchored to the bottom of every screen.
But while I’ve anecdotally observed that people are decent about organizing their homescreen, I’ve found that either out of laziness, forgetfulness, or naivety, users are less likely to organize the shortcuts in their docks. I myself took two weeks after upgrading to iOS 7 to realize that I don’t even use the baked in Music app very often, yet I was dedicating one of my four shortcuts to it.
This morning I gave some thought to what I was using frequently, and what I needed access to quickly, and did a little dock reorganization. Out was Music, and in was Google Maps – which I need quick access to sometimes if I’m sitting at a red light, or stuck in traffic. Swapping out Mail for Mailbox is something I did on day one. And Chrome for Safari is an improvement for me because I appreciate sync with my desktop browser within Chrome. I thought about iBooks, as one of the most frequently used apps on my phone, but I don’t think I ever need lightning quick access to it. Camera would be another likely candidate.
Anybody using any “dock hacks” out there? Any outside of the box apps or tricks which are invaluable to have quick easy access to from every screen?
A lot of people have asked me over the last few days what I make of Apple buying both Locationary and Hopstop in the same week. As someone who founded and ran engineering at a local data company, my opinion is likely biased, but I say it’s an important move by Apple that, with effective integration, will allow them to improve Apple Maps and other local product offerings in across dimensions.
Local data is measured on three axis: breadth, depth, and quality. Breadth consists of how much data you have. This is the easiest problem for a company like Apple to solve. They can buy or license local data from various providers – essentially just throw money at this problem and solve it quickly. Depth and quality on the other hand require much more time, engineering, and multi-pronged strategy to really live up to what users expect.
The Hopstop acquisition is a direct investment in depth (or how deep can you get on one specific attribute of local data). Hopstop immediately gives Apple best of brand support for intercity transit directions – something that is required to compete with Google Maps public transit integrations. How can I get from point A to point B is a very common mobile query, and trying to build a system that answers this yourself requires going city by city, datasource by datasource, deal by deal. Hopstop has been doing a great job of executing on this for years, and will likely to continue to do so with Apple’s resources at their back.
Based upon what I’ve read since the Locationary acquisition, I assume that this is an investment in data quality. Their CEO wrote an amazing post for Techcrunch a year ago outlining the technology required for maintaining high data quality (similar to what we built at Hyperpublic), and it looks like they’ve invested heavily in crowdsourcing to ensure freshness in their data. Combining technology + the crowd is necessary to make progress on this problem.
Unfortunately you can never fully win at solving the local data challenge because you’re working within an ever changing world where the data just isn’t always available digitally. The best you can do is show constant improvement on the breadth, depth, and quality axis and use the right mix of team + technology + crowd to keep chugging along. I’m happy to see Apple recognizing the importance of investment in this area. Congrats to the teams at Locationary and Hopstop.
As we’ve been getting started with development at our new company I have taken the opportunity to re-evaluate developer tools and workflow. At Hyperpublic I had the chance to try a lot of the tools that emerged as part of “make everything a cloud service” trend that was sweeping the late 2008-2010 era. I have stuck with many of the old stalwarts – Github (source code hosting), Pivotal Tracker (feature and bug tracking), Dropbox (files haring) – however one welcome new addition to the workflow is HipChat.
HipChat is a private group chat client developed by Atlassian, the company who brought us Jira (ticket tracking) and Confluence (information collaboration). It runs natively as an Adobe Air application, and there’s a browser based UI for search and history should you need to access a piece of information on the go. It supports multiple rooms for group chat, one on one private chat, file and link sharing, and has a useful API for integrating with other services in the workflow.
A nice benefit of integrating our other services with HipChat is the activity stream that is produced which helps everybody observe progress. When code is pushed to Github, a new pull request is issued, new comments are left, new stories are created, Chef finishes running, integration tests fail….everybody is kept up to date on progress in a way that isn’t obtrusive and doesn’t clog the inbox. I’ve noticed an increase in engagement with code reviews and an increased commitment to our intended workflow – both huge benefits. If you’re looking for a team alternative to Campfire, IRC, or even iChat I’d recommend checking out HipChat.
* Hat tip to our team member Jamie for bringing HipChat to the team.
When Apple releases iOS 7 this fall there will be a few features that capture users attention immediately: the newly designed flat UI, AirDrop, Siri improvements, and an updated Camera + Photos interface. While all of these are welcome improvements, the features that I’m most excited about are the background update capabilities.
Background updates will allow applications to update their content when the app is not running. This means that when the user opens Mailbox his new email will be waiting for him, and he won’t have to wait for it to load. When he opens Twitter he won’t have to pull to refresh and he’ll automatically be taken to the most recent tweets. And when a friend shares a Youtube video with him it can automatically download in the background so it can begin playing immediately upon the user clicking the notification.
This may not sound like a major feature, but it has the potential to improve user experience across nearly every single application on the phone. Weather, stocks, sports scores, driving directions, media, and more can all be kept up to date and made accessible immediately whether online or offline. In a world where data and services live in the cloud, and people interact across multiple devices, background updates will allow the phone to always contain the freshest content personalized for the user.
From a product development perspective, I strongly urge developers to wow their users via creative uses of background push. Apple gives developers the option to check at certain intervals for updates if they expect updates frequently (though they’ve built intelligence to optimize for battery life, usage patterns, and connectivity), or the option to push updates to users only when they become available, in the case of less frequent updates or in response to events. From this point forward, if an app icon is badged, I’m going to expect to see some new content the second I click to launch. Away with the expectation of web latency and onto the era of responsiveness becoming the norm.