Its taken us a little while to get this right but we are proud to announce the latest feature for [Markd](https://markd.co): Import from Google Contacts.



# What?

[Markd](https://markd.co) is a SAAS product myself and my co-founder Brandon [have been working on](/personal/farewell-bamboo-hello-markd/) for most of this year. Simply put, its a tool for managing your professional network.

Since the beginning we have had a [chrome extension](https://chrome.google.com/webstore/detail/markd-bookmarks-for-peopl/beaalofkiocejchbpaocbbjhobmambpp) that lets you quickly create Marks from a given LinkedIn, Facebook, Twitter or a number of other sources. Although the process is quick, just two click in most cases, we have found that some users want to Mark a great many more people.

For this reason (and because of numerous requests from users) we decided to implement a feature that lets you import contacts from other sources too.

# First Attempt

Although a great many of our users Mark from LinkedIn we decided that we would implement importing from Google Contacts first. Mainly because it has a well defined API (unlike LinkedIn) and already have some features involving Google.

Importing seems quite simple on the surface but due to the differences between a "Google Person" and a "Mark" there were some complications, but before I get to the details of that, the general algorithm for importing looks like:

1. Call the appropriate API endpoint to pull in as many contacts as desired (in our case we limited it to 2000 for now)
2. Split the contacts up into "new" contacts and "existing" ones. Because you can import multiple times there may be contacts that you have already imported.
3. For all the new contacts go through each and convert them to Marks.
4. For all the existing marks go through each and update it if it needs updating or skip it if it doesnt.
5. Gather the results of the following steps and "apply" the changes.

Although the above is fairly simple there is a subtle issue. If you remember back from [my previous post](/posts/markd-custom-fields/) on our custom fields feature we decided to implement a system where all fields on all Marks must have a "definition" first. This definition describes its "kind", its "name" and a few other properties. The idea here was that marks could share common fields which would be really useful.

The problem with this system is that it complicated the above algorithm, it forced us to load those definitions from the database then compare them in a way to determine if we needed a new definition when importing the fields from a [Google Person](https://developers.google.com/people/api/rest/v1/people#Person). Not only that if you take a look at the API for a Google Person you will notice that many of the fields have a "type", such as [EmailAddress](https://developers.google.com/people/api/rest/v1/people#Person.EmailAddress).

```
{
  "metadata": {
    object (FieldMetadata)
  },
  "value": string,
  "type": string,
  "formattedType": string,
  "displayName": string
}
```

This "type" makes sense because you might want to add multiple email addresses to your Google Person then set one as "Home" and one as "Work" etc. The issue is that the kinds of fields that Markd supports doesn't accommodate a "type" this is because the "type" was expected to be encoded into the "name" of the field definition. So for example you might attach an "email" field to a Mark and then name it a "Work Email" and then attach another "Home Email":

![](./ss-home-work-email-fields.png)

All Markd fields must have a definition that is shared between Marks whereas a Google Person field can have a differently named "type" for every field. There is a fundamental difference here between how Google structures its fields and Markd does.

The problem stems from the fact that we were planning ahead with the ability to "share" fields between Marks. Unfortunately this structure appears to be too rigid as it makes it tricky to "rename" fields. Because the name is part of the definition which is shared between all fields, if you rename the field on one mark then it forces the name to change on all Marks. This might be great for some fields but its not great for others.

After much discussion we decided to add "label" properties to some of our field kinds. So for example now an "email" kind would have the following value:

```
{
  "email": "mike.cann@gmail.com",
  "label: "Home"
}
```

Values are unique to each "field" which is attached to a Mark, they just share the same "definition".

This solved the "renaming problem" as each field could change its "label" value without affecting all the other fields. Unfortunately it also made the name of the field kind of pointless; you would add an "email" field definition to your Mark, name it "home email" then you would set the "email" and have to set the "label" to "home" too. You data was now duplicated and confusing... not ideal for Markd which prides itself on being simple and fun.

# Second Attempt

So we had a fundamental issue with field structures between Markd and Google. After having spent the best part of a week designing and implementing imports around our current structure of fields we were reluctant to go back to the drawing board. In the end however we decided that it was important enough to our core principles that we spend the time now to get it right.

The main issue was around our field structure. We wanted the ability to share definitions between fields for future features but in actual fact right now we weren't using it for anything, it was kind of getting in the way and adding "accidental complexity" to the system. We didn't need it. So we reluctantly decided to remove it.

Instead of all fields having a shared definition we decided to change fields so the definition is embedded right alongside the field. This meant that every field on every mark had its own embedded definition. This ensured that each field could be renamed without it affecting all the other Marks.

We could loose those "label" properties we added and simply have the name of the embedded definition become the "label". So for example when we import an EmailAddress field from a Google Person the "type", "Home", would create a new field that has an embedded definition with a name of "Home Email Address".

It took us a few days to re-architect the whole system to use this concept of embedded definitions instead of linked ones then migrate all the old fields over to the new type. Another day or two was spent changing the import code to use the new fields system.

# Conclusion

It took a bit longer than I would have liked to complete the feature but in the end I am really happy with what we ended up with. Everything is considerably simpler and easier to reason about than before. IMO this is super critical when trying to build systems that you want to iterate on.

# Future Plans

One thing that the old system of fields gave us was a quick way to add fields that you have added before to a Mark, so say you have created an "Home Email" definition, you could with one-click re-add that to another Mark without having to type out "Home Email" again.

We realized that this could be implement in the new system in very much the same way we do with tags, we simply query the database to see which fields are commonly used on your marks and present those as "Common Fields" to add. For now we have left this addition as a "phase 2" for future development while we move onto other things.

We also plan on layering on "linked" definitions once more at a later date once we have a use-case that we want to support.

Now we have a good flexible system of fields you can expect other import sources such as LinkedIn to come soon, stay tuned!

I recently had the opportunity to experiment with something I have been meaning to play with for a little while, Google's Polymer.



I first heard about Polymer at Google IO 2014:

<iframe width="853" height="480" src="https://www.youtube.com/embed/8OJ7ih8EE7s" frameborder="0" allow="autoplay; encrypted-media" allowfullscreen></iframe>

I highly recommend watching that video if you want to know more about Polymer but the high level idea is that its a library built on top of the new HTML Web Components and it allows us to write our own custom HTML elements in a way that makes sense.

I really liked the look of it as it reminded me greatly of Adobe's Flex (MXML) in the way you can write your own components in a declarative manner then bind to various data in the code behind.

So it took me a few days to get my head around things to begin with. One thing I would recommend if you are interested in tinkering with Polymer then first checkout this video:

<iframe width="853" height="480" src="https://www.youtube.com/embed/INH_OW4lFSs" frameborder="0" allow="autoplay; encrypted-media" allowfullscreen></iframe>

I wish I had used that to begin with as it would have saved me a whole heap of "is this the correct way to do it?" headaches.

One complication with my setup however is that I really wanted to use Typescript rather than raw Javascript for my code. Well fortunately Visual Studio has really great Typescript support and I was able to create a Typescript project in Visual studio and get cracking immediately.

I ran into an issue with how to use Polymer with Typescript however and there wasn't too much info on the web out there so hopefully this short guide will help:

## 1) Create your custom element

I'm using a login element as an example:

**login.html**

```html
<link rel="import" href="/bower_components/polymer/polymer.html" />
<link rel="import" href="/bower_components/paper-toast/paper-toast.html" />
<link rel="import" href="/bower_components/paper-button/paper-button.html" />
<link rel="import" href="/bower_components/paper-input/paper-input.html" />
<link rel="import" href="/bower_components/paper-fab/paper-fab.html" />
<link rel="import" href="/bower_components/core-icons/core-icons.html" />
<polymer-element name="tt-login" attributes="userService">
  <template>
    <style>
      .card {
        margin-top: 64px;
        max-height: 580px;
        max-width: 512px;
        box-shadow: 0 2px 5px 0 rgba(0, 0, 0, 0.26);
        border-radius: 2px;
        padding: 20px 16px;
        box-sizing: border-box;
        background-color: white;
      }
    </style>
    <div class="card">
      <h1>Login</h1>
      <paper-input
        floatinglabel
        label="Your
email"
        type="email"
        value="{ {email}}"
        error="Input is not an email!"
      ></paper-input>
      <paper-input
        floatinglabel
        label="Your password"
        type="password"
        value="{ {password}}"
        error="Input is not an
email!"
      ></paper-input>
      <div horizontal center layout>
        <a href="/#signup"
          ><paper-button
            disabled?="{
{isLoggingIn}}"
            >Signup</paper-button
          ></a
        >
        <div flex></div>
        <paper-button
          id="check"
          on-click="{
{login}}"
          disabled?="{
{isLoggingIn}}"
          >Login</paper-button
        >
      </div>
      <paper-toast id="errorToast"></paper-toast>
    </div>
  </template>
  <script src="login.js"></script>
</polymer-element>
```

Its a pretty simple login element with some binding using some of Google's paper elements but hopefully you get the idea.

## 2) Create your custom element's script

**login.ts**

```typescript
class Login extends PolymerElement {
  userService: UserService;

  email: string;
  password: string;
  isLoggingIn: boolean;

  errorToast: PaperToast;

  ready() {
    this.errorToast = this.$.errorToast;
  }

  login() {
    this.isLoggingIn = true;
    this.userService
      .login(this.email, this.password)
      .then((user) => this.onUserLoggedIn(user))
      .fail((err) => this.onParseError(err));
  }

  private onUserLoggedIn(u: Parse.User) {
    this.isLoggingIn = false;
    this.fire("logged-in");
  }

  private onParseError(error: Parse.Error) {
    this.isLoggingIn = false;
    this.errorToast.text = error.message;
    this.errorToast.show();
  }
}

Polymer(Login.prototype);
```

Here we define the variables that we are going to bind to in the element. We also include the "userService" which is an attribute that is a dependency passed into the element.

Note that im able to use this.\$ to access the "errorToast" element by ID. Im able to do this because Login extends a class I wrote called PolymerElement:

```typescript
class PolymerElement {
  $: any;
  style: any;
  fire(eventname: string, payload?: any) {}
  addEventListener(eventName: string, handler: (e: CustomEvent) => void) {}
}
```

For now it a bit of a hack to get around the fact that Typescript requires that you implement all elements in an interface so I cant just do "class Login implements HTMLElement".

Note also the call to Polymer:

```typescript
Polymer(Login.prototype);
```

We must pass the prototype into the call then do our variable initting in the ready() function.

## 3) Use the element

Now we can use it pretty easily:

```html
<!DOCTYPE html>
<html>
  <head>
    <meta charset="utf-8" />
    <meta
      name="viewport"
      content="width=device-width, minimum-scale=1.0, initial-scale=1.0,
user-scalable=yes"
    />
    <title>Login Example</title>
    <script src="bower_components/platform/platform.js"></script>
    
    <script src="lib/polymer_utils.js"></script>
    
    <link rel="import" href="login.html" />
  </head>
  <body fullbleed layout vertical unresolved>
    <userService id="userService"></userService>
    <login
      userService="{
{$.userService}}"
    ></login>
  </body>
</html>
```

I hope that helps other that are looking to do their own tinkering with Typescript and Polymer!

[![](/wp-content/uploads/2010/12/700.jpg "700")](/wp-content/uploads/2010/12/700.jpg)

**EDIT: I now have a newer, better version of this called "[Recursive](/posts/recursive/)"**

Depending on your level of geekness you may or may not enjoy this one.



I proudly present [Chrome Crawler](https://chrome.google.com/extensions/detail/amjiobljggbfblhmiadbhpjbjakbkldd), my latest Google Chrome extension:

[![](/wp-content/uploads/2010/12/Shot_002.png "Shot_002")](/wp-content/uploads/2010/12/Shot_002.png)

The idea is simple really. You just give it a URL, it then goes off and finds all the links on that page then follows them to more pages then gets all the links and follows them and so on and so on.

Along the way it checks each page to see if there are any 'interesting' files linked there, if it finds an interesting link it will flag it for you so you can check it out.

Theres an options page that lets you customise the way it all works:

[![](/wp-content/uploads/2010/12/Shot_004.png "Shot_004")](/wp-content/uploads/2010/12/Shot_004.png)

If you are still confused check out the video below:

<iframe width="100%" height="400" src="https://www.youtube.com/embed/ceeQEMTSD0I" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>

So why did I make this? Well to be frank, I made it mostly "just 'cause I can"!

Also having learned from my last Chrome Extension project [PostToTumblr](/posts/my-first-chrome-extension-post-to-tumblr/) I realised the Chrome API allowed you to do some things that you wouldn't normally be allowed to do on a website (nameley the [Cross-Origin XHR](https://code.google.com/chrome/extensions/xhr.html)) and I wanted to do something to take advantage of it.

It didnt take me long to knock out this project, one lazy Saturday for the majority of the code and today for a quick fix or two and to write this post and make the video. As such I expect there to be many bugs and problems so if you encounter one drop me an email (my address is found in the options page).

Oh finally, I wouldnt try using this on a google page as you will likely end up seeing this quite often:

[![](/wp-content/uploads/2010/12/Shot_003.png "Shot_003")](/wp-content/uploads/2010/12/Shot_003.png)

Anyways you can grab it over on the [Chrome extensions gallery here](https://chrome.google.com/extensions/detail/amjiobljggbfblhmiadbhpjbjakbkldd). If you enjoy it please leave me a review / comment, much love!

[![ScreenHunter_02 Nov. 12 08.15](/wp-content/uploads/2009/11/ScreenHunter_02-Nov.-12-08.15.gif "ScreenHunter_02 Nov. 12 08.15")](/wp-content/uploads/2009/11/ScreenHunter_02-Nov.-12-08.15.gif)

They are upping my gmail, picassa, whatever, storage from 10gb to 80!



[![ScreenHunter_03 Nov. 12 08.17](/wp-content/uploads/2009/11/ScreenHunter_03-Nov.-12-08.17.gif "ScreenHunter_03 Nov. 12 08.17")](/wp-content/uploads/2009/11/ScreenHunter_03-Nov.-12-08.17.gif)

Happy days!

I just thought that not everyone knows what Google Wave actually is. Well this video does a good job of explaining it in like 2 mins:



<iframe width="100%" height="400" src="https://www.youtube.com/embed/rDu2A3WzQpo" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>

[![2009-10-15_1400](/wp-content/uploads/2009/10/2009-10-15_1400.png "2009-10-15_1400")](/wp-content/uploads/2009/10/2009-10-15_1400.png)

Had my first proper real-time wave today and although I was a little skeptical at first I must admit it really worked very well and surprisingly was actually alot of fun!



Im honestly not sure whether it will take off and become the 'next big thing' or not, but I hope so! I would love to write all my blog-posts, emails, msn conversations in one convenient place and have realtime updates an backups.

Anyway, if you are lucky enough to be in the preview add me mike.cann@googlewave.com and we can have a chat about it :)

**EDIT:**

As a quick edit, i have just installed a new plugin for wordpress that lets me embed google waves, so if you have google wave you should beable to see the following wave in full:

[wave id="googlewave.com!w+65k3TZQWA" color="#000000" bgcolor="#ffffff"]