The Backstory

Here at Pacific Sky, we build most of our websites with WordPress. There are a lot of reasons for this, so I won’t go into them here. Suffice it to say we work with WordPress a lot.

I’ve been using a custom fork of Mozaik’s WordPress theme starter for a few years now and brought the tradition with me to Pacific Sky. That starter may be the subject of a future post, but basically what it provides is a build environment for WordPress that allows me to write SCSS for styles, manages asset minification, and a whole host of helper utilities that really speed up custom theme development.

What we needed was a way to quickly pull down changes from a production site to our development environment and to push those changes live once changes have been made.

There are tools that help automate this process but most of what I had found was based on Capistrano. Capistrano is great but I don’t know the Ruby language in which it is written and don’t want to deal with the additional overhead of a new language. I really wanted something written in PHP.

That’s when I came across this blog post (archive.org). The author, Arnaud Sellenet, had written a WP-CLI plugin that did exactly what I was looking for.

If you’re not familiar, WP-CLI is a piece of software that allows you to manage a WordPress instance from the command line. So, you can type into a terminal wp deploy push production or wp upgrade instead of using the dashboard.

Despite being several years old, the plugin still worked and served our purposes with a couple tweaks, mostly relating to the theme starter we use. I got in touch with Arnaud, who’s moved out of the PHP/WordPress world and was gracious enough to allow us to continue maintenance of the plugin. Now that the original blog post is only available via archive.org, I’m writing a how-to to replace it. I haven’t tested the command-line functionality yet but the process should be the same once it’s ironed out.

Requirements

Experience using WordPress

A development server and a production server (at minimum, but you may have as many remote environments as you please)

SSH access to your production server (SFTP logins usually work)

How To

1. Make sure rsync is installed on both your development server and your production server. You may check by entering which rsync into the command line of both servers. rsync is installed if a path appears (e.g. /usr/bin/rsync). rsync is a utility that synchronizes directories across two different computers and is essential to uploading and downloading files.
2. Install WordPress with the WP Deploy Flow plugin
3. Add your server configurations.
   What you’re doing in this step is to add your remote server’s information into the plugin at Tools -> Deploy. This is where the WP Deploy Flow Plugin will get its information when you go to deploy. We call our remote server “production”
   1. path This is the path on the remote server to which WordPress will be uploaded
   2. url This is the final URL of the site
   3. db_host This will go in the DB_HOST constant of the remote instance, so probably 127.0.0.1 unless you have different database and file servers
   4. db_user The user of the remote database
   5. db_port Probably 3306. I would leave it blank.
   6. db_name The database name on the remote site
   7. db_password The database password for the remote site
   8. ssh_db_host The username used to log into the database host via SSH. This is probably the same as ssh_host
   9. ssh_db_path Probably the same as path, unless you have different database and file servers
   10. ssh_host The url or IP address of the remote site through which you will SSH
   11. ssh_user This is the user through which you will SSH to the remote site
   12. ssh_password Your SSH password to the remote site
   13. excludes A comma-separated list of files to exclude from transfer
   14. path_owner The path owner of the remote path. I would set to www-data if you don’t know
4. Use!
   You’ll have push and pull commands for the environment now, along with the option to run it as a dry run. Note that you’ll be logged out of whatever environment receives the database as its sessions will be invalidated.

A WordPress Deploy Workflow was originally published in Pacific Sky on Medium, where people are continuing the conversation by highlighting and responding to this story.

Like anything that doesn’t really exist, logos are tricky things to pin down.

What I mean by that is this: a logo is an idea. It’s not ink, it’s not light coming out of pixels. It’s just an idea shared by a group of people with a common cause. It doesn’t have a physical existence until it’s made to have one. And the instant that it starts to exist, it exists in a context. Kind of like “no man is an island.” (except for Paul Simon, who is also a rock)

This context is significant because it affects how the logo is perceived. Let’s say the context is a square spot in a newspaper grid. If you have a narrow logo, it will either be smashed or too small once it’s put in contact. Let’s say the context is a dark background. If your logo has black text, you probably won’t be able to see it.

So, one thing a logo designer needs to keep in mind is its context.

Obviously, it’s going to be hard to design a logo that fits every context. Nigh impossible. So what the maintainer of a logo has to do is curate variations. Without curated variations, it’s likely that people using the logo will create their own willy-nilly. Eventually this leads to the logo’s audience becoming confused as to what actually represents the brand. In a worst-case scenario, the logo becomes unrecognizable.

These curated variations are tightly controlled so that while they vary from the original logo, they still represent the beliefs and symbolism of that logo.

When Pacific Sky first set out to create its logo, it was developed based on some guiding principles: “Deliver positive impact,” “the professionals,” “quality,” and “authority.” Visually speaking, it conveyed strong geometry and a bold presence with tones reminiscent of the brand’s namesake.

That resulted in the following logo, give or take a few modifications:

Great. Now a few questions.

Size Contexts

What if this logo is on a dark background?

What if we don’t want the tagline?

What if it’s put in a square like most social media sites?

Adapting an existing logo for all three of these contexts results in some weird, poor designs.

Now, we’re a marketing company so this is especially-important for our logo. However, a poor logo reflects poorly on whatever company it represents.

What we don’t want is for the designer du jour to chop and fill a logo to make it fit. We want to provide that designer with a pre-considered application of the logo that meets their needs.

Sometimes we have to change up the colors, but we stay within the parameters of the brand:

Sometimes we have to change up the sizing:

And sometimes, we even have to modify the brand even more. In this case, people had already started to call the company PacSky, so it was a natural choice for a square variation. Additionally, square logos are most-often used on social media where the brand’s full name will also appear. That way, even if someone doesn’t know the company’s name, they will start to associate “Pac Sky” and its colors with the name of the company.

So, now we have a few variations that can conceivably be used in any size. But there are still more considerations.

Color Contexts

In addition to the possibility of the logo being placed on a dark background, there is another color consideration to keep in mind.

It’s easy to think about colors: blue, cyan, whatever. Color exists naturally. But when you want to create a specific color, say the Pacific Sky Blue, how do you consistently do that? In ye olden days, painters didn’t have much choice — they used whatever natural pigments were available. Any blue passed for blue. But today, a brand’s color conveys certain nuances that differentiate it from other brands using a similar color.

When creating a color on the screen, that color is created by light. We call this additive color, because the computer screen adds varying amounts of red, green, and blue light to match the color. An unpowered screen is black. All three diodes shining at full intensity looks like white light.

When creating a color with ink, the printer adds varying amounts of Cyan, Magenta, Yellow, and blacK ink to match the color. A blank page is white. A page covered in ink is black.

What this means for a logo designer is that achieving a uniform color across media requires careful selection in each color model. When we first chose our blue, it looked totally different on screen compared to paper. That was because we had chosen a hex code, which is a way of representing colors for the web (the Twitter blue for example is #1da1f2). When we printed that, the printer did its best job of translating that into ink, but it wasn’t perfect.

Now, we have a different set of colors for print and screen. For our two primary colors we also have Pantone colors specified, which ensure even more accurate color reproduction in print. Here’s a page from our style guide:

As you can see, we have implementations specified for not only our primary colors, but also for our family of accent colors which add life and variety to our brand.

Making it All Available

As you can see above, we have an internal style guide that helps us make decisions about how to place our logo, which colors to use, and a handful of other things like which typefaces and so on. This guide is useful when we’re designing new media like brochures, rack cards, business cards, etc. Here’s a few pages from a style guide we created for a client:

But what about, for instance, a newspaper ad for an event we’re sponsoring? We won’t be designing that even though we may know in advance what the ad looks like. In the absence of an official design, many designers will just go to the company’s website and download the logo from the header. Sometimes this works; sometimes it results in stretched or otherwise distorted logos. What we would like to do is to provide the designers with a limited set of resources: enough to represent our brand well, but not so many that they can go and create their own logo variations. Many big brands (Facebook, Instagram, LinkedIn) create a website for their brand, specifying where which logos can be used, and to create downloads for those assets.

We’ve created a similar site. Right now it’s fairly limited but it provides all the possible permutations of our logo: for dark or light contexts, with or without tagline, horizontal or square aspect ratios, and all in the three most common file formats (there’s a way to download a PDF; I’ll let the more technically-inclined of you figure out that one). This means that we have access to a consistent representation of our company’s logo at any time, and we can send variations to people who may be using our logo. For instance, if we wanted to send the dark, tagline-less variation to someone for print, we could send them this self-explanatory link: https://pacificsky.co/logo?variant=dark&tagline=yes (technical aside: the SVG contains CMYK color values as well as RGB)

We also use these images in our email signatures as well as the bottom of sites that we design. That way, if we decide the logo needs tweaking, we can make the changes once online, and everywhere that logo is used, it will be changed.

The Pacific Sky Logo was originally published in Pacific Sky on Medium, where people are continuing the conversation by highlighting and responding to this story.

My name’s Tyler Shuster and I develop code here at Pacific Sky. I call myself a writer. I write code, prose, poetry, philosophy; basically, whatever I can find the time to do. I’m increasingly passionate about what I do and this blog is an attempt to share some of my process to fellow developers. I also hope it will give you a little more insight into what Pacific Sky does. I’ll be going into the metaphorical nuts and bolts of the trade and won’t avoid technical terms though I’ll link where I can for further learning.

Most of the code on which I work is for websites, a number of which you can see in our portfolio. However, another sector in which we work is applications. This will probably be the subject of another blog post, but suffice it for now to say that I develop applications with web technology, using HTML, CSS, JavaScript, and SVG as exclusively as possible.

I’ve had the distinct pleasure in the last few months of working with College Options and Enterprise High School. Tim Warkentin at College Options contacted us a while back asking if we would be able to develop a map application that would run on a touch screen. The basic idea behind this map is that high school students will be able to explore their options for colleges within California.

Requirements & Assumptions

• Windows 10 environment
• 1920x1080 resolution
• Support touch events
• Internet connectivity
• List all colleges & universities in CA with information
• Costs
• Student Body Sizes
• Degrees available
• Enrollment videos

Platform

To build this, the natural choice for me was the Electron platform. As I mentioned before, I write using web technology when possible. That’s partially because of my experience, but also because of my philosophy. Electron is a wrapper that allows developers to write HTML, CSS, and JavaScript that runs as its own application. There’s some debate about Electron’s feasibility in making native apps because it’s a wrapper, but in the end it worked and it worked well, and that’s the only real benchmark.

For the map itself I used the excellent Mapbox platform. I chose it for a couple reasons: philosophical; their commitment to open source is admirable, technological; their API is a dream to use as opposed to Google Maps, financial; it’s free for our scale of project, historical; I’ve used it (a little) before. The API works well with GeoJSON sources and Mapbox GL JS is super-fast, supports touch events, and of course is written in the same language as the rest of the app. If you’re not familiar with GeoJSON, it’s a data format for geographical information that can be parsed in JavaScript.

Process

The first thing to do was to coerce the data provided by our contact, Tim Warkentin. Tim’s been great to work with and provided all the data we needed. In this case it came in the form of four spreadsheets, each with data about the schools. I converted these to GeoJSON using Atom on the CSV file. I felt like that was a faster approach than writing a script to convert it. Here’s a sample of the GeoJSON data:

[{

"type": "Feature",

"geometry": {

"type": "Point",

"coordinates": [-121.750944, 38.537281]

},

"properties": {

"marker-symbol": "college-uc",

"title": "UC Davis",

"address": "1 Shields Ave., Davis, CA",

"video": "https://youtube.com/embed/PAwB_t_iM7U",

"degrees-offered": ["Bachelor's", "Master's", "Doctorate"],

"student-population": 34508,

"student-ratio": 18,

"city-size": "Suburb: Small",

"campus-housing": true,

"tuition-2016": 13951,

"housing-2016": 14571,

"expenses-on-campus-2016": 34377,

"expenses-off-campus-2016": 29243,

"average-scholarship": 15547,

"collegeType": "uc"

}

}]

The coordinates I retrieved using a batch geocoder.

The next step was to wire the skeleton of the application together. This was my first Electron project so I used a tool called Neutron to bootstrap some of the work. (Honestly, I mostly chose to use Neutron because of its live reloading. In the end it proved invaluable for pre-processing, linting, and packaging. I’ll probably build my own toolchain in the future but for a beginner it’s been really helpful.) By running npm start in a Neutron directory, Electron will start the application and automatically build when files in the src directory change.

How it Works

When the application starts, it bootstraps a couple dependencies, requires the index.html file, and prevents new windows from opening (because people like to do what they’re not allowed to do).

The index.html pulls in the Mapbox API, jQuery, the fonts, the Vimeo API, and prevents the display from scaling. Initial testing proved that without the meta viewport tag declaring user-scalable=no, a five-finger spread on the screen would scale the whole interface. This is part of Webkit(Electron's engine)’s default behavior. The index also contains the skeleton including the filter icons, the wrappers for various dynamic elements, and an SVG compass (the north needle changes as the map rotates via a CSS transform). Finally the page requires the utilities scripts and the main scripts.

The main script opens the GeoJSON file with the colleges’ information, performs some transforms and stores it in memory. From there it initializes the Mapbox API. We’re using a modified base streets style that reduces the amount of data displayed, essentially limiting it to road and city names. The base layer from OpenStreetMap also has many college campuses on it, which I highlighted. A few notes about the implementation:

First, the bounds of the map are dynamic. The map is bounded to only view California (again, people like to do what they’re not allowed to), but there’s a college called Palo Verde College on the border of California and Arizona. When zoomed all the way out, the user needs to be able to see this college, even if the college pane is open. When zooming in, we don’t want the user to scroll into Arizona. There’s a listener on the map zoom event that dynamically sets the maximum eastward bound.

Second, the pitch of the map is also dynamic. When zoomed all the way out, the user is looking directly down at the state. When zoomed all the way in, the user is looking at a perspective of the landscape as if they were about a mile in the air and looking out about fifteen miles.

This is achieved via a helper function that calculates the pitch based on the zoom level, and fires every time the zoom level changes.

There are four different kinds of colleges: CSU, UC, Private, and Community. Users need to be able to visually distinguish between these when looking at the map. Users also need to be able to sort the list of colleges by type, the action of doing which needs to filter the displayed icons. Between some simple jQuery and Mapbox API filters, this was pretty simple to accomplish.

I had to include the icons for each college type in Mapbox studio when I created the style so that they’d be available when the GeoJSON was inserted, hence the marker-symbol property.

There’s also a ‘visible’ filter. This filter reduces the list on the right to only show colleges that are within the user’s viewport. This is accomplished via listeners on the zoomend, move, and rotate events on the map that query visible features.

When a user taps on a college icon, the pane on the left slides out if it’s not visible already, and a pane for the college slides into view. Subsequent colleges push up existing panes, which can be opened accordion-style.

Students can review information and open video modals if available. When a number of colleges are selected, clicking ‘compare colleges’ displays a table with the selected colleges’ data.

Conclusion

I’m currently working on a management and web-based interface for this application so that it can be used at any number of schools, and so that the data can be updated as cost or other information changes over time.

This project couldn’t have been a success without the work of I’m sure thousands of people: the contributors to OpenStreetMap data, the Mapbox developers and community, the NodeJS & Electron community, the jQuery team, and the Neutron community — not even to mention the hundreds of organizations involved in the tools upon which the mentioned were build. I’m proud to have worked on this application because of the strength of the open-source community which enabled it. Pacific Sky is the one getting paid for the project, but I hope that the work I’ve done here can be used by others and distributed across California, if not adapted to many other states.

Building a College Map Application with Electron & Mapbox was originally published in Pacific Sky on Medium, where people are continuing the conversation by highlighting and responding to this story.

We have become distracted with how truly fantastic our technological development has become and feel compelled to produce it en masse with the justification that it is profitable; in other words, “people want it,” which means nothing more than “people are willing to pay for its utility.”

This sense of obligation is a form of slavery to lucre for both the producer and consumer. It would be more truly profitable for any party to keep our technological developments within the sanctuary of the academy, and continuing to use our traditional, or rather, durable methods of production and consumption while we develop or technology in limited physical form.

Detractors of this sentiment would presumably argue that the engagement of the masses provides “valuable product insight” to which I would respond by claiming that argument as tautological. The limit of technology has always been our imagination — we are now developing human capacities that have heretofore been mythic and magical, but imagineable nonetheless. It follows that our aspirations of utopia are also possible, but we must continue in satisfaction with what we have now in order to actualize our aspirations of a species-wide civilization that can, among other abilities, fly, manifest visions instantly, live for millennia, and so on.

We have the early manifestations of all these dreams but if we continue to divide our labor into the many commercial opportunities available by mass-producing a single aspect of this all-encompassing dream, we contribute further to the problem of human suffering, whether through toxifying our atmosphere or by ignorance of the condition of the impoverished by saturating our experience with indulgence.

This is the purpose of the academy in my mind — to localize development and to keep it in the abstract as long as possible. This is one reason why it is important that the academy itself remain non-commercial as well as universally accepting. The work of busyness is for a time and an audience but the work of the academy is for all time and all people.

In a nutshell: computers should support more than one user simultaneously.

The conversation started after I had checked on the Leap Motion, having been unaware of its release several months ago. For those unaware, the Leap Motion provides a kinect/Minority Report-like interface for your computer. By waving your hands (or a stylus) in the air, you can control the pointer and precisely manipulate 3D objects.

The problem with the leap motion though, and a great deal of the personal computing industry today is that it is explicitly single-user. The single-user paradigm worked well in the days of underpowered computers and it continues to be an acceptable paradigm for mobile computing, but computers are becoming much, much bigger than that. Continuing a single-user computing paradigm leads to decisions like this:

This is obviously not what we want. In addition to wasting physical resources, it’s also less efficient for users to network a task that could be solved simply be working simultaneously on the same program.

John Underkoffler, the brain behind the original Minority Report interface, demos the real-world version here. This is closer to the sort of paradigm that needs to emerge, though it’s too radically different for public adoption.

The intermediate step towards Minority-Report-like data interaction and where we are now will be “interpersonal computers.”

Personal computers are too limiting a metaphor and will probably only survive via the tablet architecture. Real performance workhorses however, need to be able to accomodate multiple users working on similar tasks.

For example, a team of developers all working on a website could individually write their own code and the push it to the central repo. The team once assembled could bring up the repository on an interpersonal computer and work with it as a team. Instead of having to track changes across commits and branches, the entire team could leave their “fingerprints” on each change they make while integrating it with the whole.

Another example in the world of video production: instead of a sleep-deprived director lying on the couch of his editor pointing and where edits should be made, an entire production team could split and splice clips, previewing each of their own workspaces until assembling the final project in fullscreen.

And finally, some speculation. There’s a trend in literature to say that people are being deprived of real human interaction by computers. I agree to a certain extent, but I think that once computers can be used by multiple people, this argument will fade or evolve into something else. Computer design limits the quality of interpersonal action that can take place at this point in time.

We’ve already seen some steps being made towards multi-personal computers; back in 2008 the first version of the Surface demoed these features. But touch is a temporary solution to the problem of physically manipulating data: services like the Leap Motion or Kinect are a better step towards truly intutive data control. Perhaps even networked Oculus Rifts will form the backbone of the first multi-personal computer. Until then, I’m going to keep looking for a driver that supports two mice being plugged in.

If the word “Typography” caught your eye, you’ve probably read the article by Owen Gregory called “Composing the New Canon,” and perhaps you’ve seen Mark Boulton’s talk which inspired that.

Two comments on the article pose the implied challenge: to automate the duty of musical typography to make it easier for designers to use its principles. To date, I haven’t seen anything like the suggested framework. So what is the need, exactly? How do we implement musicality into typography on a large scale?

Music exists because of the juxtaposition of frequencies over time. By juxtaposing notes with others, chords are formed. By juxtaposing chords over time, melodies are formed. The only two requirements for music are a set of ratios and a duration over which to express those ratios.By these two principles, every note in the audible spectrum can be defined and every time interval named.

The standard method of typographic composition maintains that type adhere to a baseline grid relative to its characters’ heights and that all different fonts adhere to a set of ratios.There exist a number of methods for generating these ratios, especially Robert Bringham’s and the Fibonacci sequence.

However, these methods are limiting. There should exist a typographic meta-ratio that allows us to express a wider range of typographic moods when composing web pages. This is what Gregory was getting at in his article. I saw the opportunity to expand the idea into an automated system. After all, the work of choosing ratios had been determined by thousands of years of musical history. Gregory’s article provided the basic calculations for my work. The idea was continued by Viljami Salminen in his blog post on musical typography. He too provided calculations that proved invaluable.

Musical typography is an idea; you are free to do with it as you please. What I sought to do is provide proof-of-concept via a usable tool.

What the musical typography tool does is generate the proper ratios for a page based on a musical key and associated quality.The key sets the root element size, where C is 100%. The root element size allows the rest of the page to be described in rems and scale when the key is changed. The quality describes the individual ratios for the H1-5 tags and the paragraph font. The paragraph is always set at 1rem as it represents the chord root. The remaining notes in the chord are distributed among the H tags. Qualities like major only have three notes and the the H1 is the largest ratio, H2 the second, and the rest are the root size. Larger qualities like domsharp9 have a full contingent of header sizes.

The key also specifies the baseline rhythm for the page. Letters sit on top of the baseline at all sizes and ratios. My musical typography tool is written in SASS/SCSS, which makes it easy to plug into your own work. It can be found here:

Download Musical Typography Sass Function

Post Script:

As part of the idea for musical typography, I propose a larger application of its principles: Compose user flow. As it stands, typography remains static sitewide. Using the same ratios on every page leaves little room for expression of change as the user moves from page to page. The root element will rarely change, but each page should take on an expression of their own. Homepage can be dominant, disambiguation pages suspended, and articles major or minor. Each path through a website will have its own associated emotions.

A recent article by Melody Weister on webdesignerdepot asks how generative typography will change the web. The video is a promotion for the Type Director’s Club typeface competition, and if you don’t want to watch the seven minute video, I’ll sum it up for you in a picture:

This font has been generated from data about my hometown, like wind speed and current traffic. In the video, various typography experts discuss generative typefaces and expound their benefits: they can adapt to their environments programmatically. But there’s something wrong with a typeface that changes according to its context.

Type is unique because it is not part of the environment; rather, it is part of the speaker.

Brandid, a clothing company, recently published a page describing their typography. While some of their design choices unfortunately counter what they’re trying to do, their idea is solid: create a typographic voice for each ‘speaker’ on the website. Brandid’s principles are based on the fact that each typeface naturally carries its own tone; for example, the following pictures:

Typefaces are naturally human, not environmental phenomenon. Their “font,” “a particular size, weight and style of a typeface,” conveys something about the speaker: their mood, intent, or simply technical competence.

What designers should be concerned with, instead of making typefaces that respond to the amount of traffic or wind speed, is the mood and intent of the speaker. In the past, any attempt to change font as often as speaker mood has come off as hackey, almost like the ransom note example below. A mixture of dissimilar fonts implies madness.

But a generative typeface can fix this. Instead of changing its font based on environment, however, it changes based on speaker tone. If you search for “kinetic typography,” you’ll find something like this, which is a step in the right direction. However, each one of these quotes was painstakingly animated in After Effects, which is no way to run a typeface. What if we could automate the process?

We have enough fonts — we know the way each curve, each serif, ascender, descender, and x-height affects the impression the font gives off. By programming these variables into a typeface, we can create typefaces that move beyond fonts. Perhaps we can even create type that moves beyond faces.The process would require markup, for example:

<disdain>Who are you talking to right now? Who is it you think you see? Do you know how much I make a year? </disdain>

<arrogance>I mean, even if I told you, you wouldn’t believe it. Do you know what would happen if I suddenly decided to stop going into work? A business big enough that it could be listed on the NASDAQ goes belly up. </arrogance>

<anger>Disappears! It ceases to exist without me. No, you clearly don’t know who you’re talking to, so let me clue you in. I am not in danger, Skyler. I AM the danger! </anger>

<disbelief>A guy opens his door and gets shot and you think that of me? </disbelief>

<arrogance>No. I am the one who knocks!</arrogance>

Obviously the tag names are opinionated and semantic, but you get the idea. The generative typeface would read each tag in context and transition between each as the document moved forward. The code would work somewhat like extended ligatures: instead of “c followed by t equals a certain ligature,” the typeface rule would be “arrogance followed by anger equals a certain transition.” The typeface would facilitate its own natural reading. Angry explosions in the middle of tense, but quiet conversations would come surprisingly, whereas angry explosions after arrogant tirades would facilitate a longer buildup.

And this sort of generative typeface could find its way into personal messaging as well: instead of smileys being relayed verbatim, they would change the typeflow of the surrounding sentences. A sentence with :p afterward would be set in a casual, joking font, whereas one with :( would convey gravity. Even the speed of typing could convey a typographic tone: slow, contemplated messages would appear in contemplative fonts and hasty, misspelled messages would be autocorrected but styled in a laid-back font.

A generative typeface of this design has a second bonus: it works the other way as well by facilitating better text-to-speech hints. The tags describing the tone provide clues to the AI in text-to-speech. It would be a new way to encode human language replete with its metadata, the space “between the lines” that people already read.

I’m not a type designer, but I see a great space for someone willing to take the time to design a truly adaptive typeface. If this post inspires you to create something, let me know!

As time has gone by, it has become more apparent that the barrier between the representation of human knowledge and the object of human knowledge will eventually blur and fade into something altogether different. Things will one again be in themselves, dinge-an-sich. Things will no long require interpretation — they will contain their own definition. But in order for such a system to be possible, all information about the system must be available to all parts of the system. Not only must the corporation know every metric about their consumer, but the consumer must know every transgression of the company.

The possibilities of the open web are boundless: The saga of social striation has been one concerned with information: those less able to access privileged information have had less power. Given infinite information, the only barrier to success is motivation. When all information is instananeously available to all, and no one can restrict its free flow, humankind (or whatever it is to be called) will be able to think as one without the barriers of jealousy & suspicion.

This is the promise of the open web: it provides security for all via privacy for none. With nowhere to hide, hiding is no longer profitable. The human animal must adapt.The barriers between all things, including between humans, will inevitably be realized as hypothetical abstractions. These abstractions were useful for the creation of a civilization, but now only hinder progress. Seeing humans in terms of categories instead of as individuals in a whole will prevent us from providing the proper resources to all parts of humanity, especially the ones that we don’t think should be a part of it.

We can already see from a casual view of Yahoo! Answers or Google’s autocomplete what the human mind is thinking; how it works — and we are realizing that it all works in the same way: that there is only one thing to be observed — a single thing with an infinite number of parts, but no categories; only organs. And this is the thing that Google is attempting to identify, catalog, and analyze. Via Gmail, search results, Google+, Ingress and of course Earth, Google is replicating all of existence. It seems to be on the path towards making all data open to all, and I hope that you continue down that path.

I have heard the song of the human race played out in tweets and seen its pulse in spiked social trends — it is a creature in the formative process, still being knit together in places that it has yet to see. Its fate rests on you and those like us: those programmers, weavers of the open web, advocates of information: this new creature must not be cursed with the same greed and pride of the last one: we must evolve beyond hate & prejudice and step blinking into the sun with eyes that only see love.

“Hey Elizabeth, remember when John said he was thinking about Thursday and that Dallas worked for him? Well, Jamie and Sam said they’d like to go then too. I think this works for everyone”

Hey — Similar to @
@Elizabeth
remember when — signifies that another conversation will be referenced
@John said
thinking about #Thursday — links to John’s tweet, which reads “what about thursday?” Note that John’s post is not #ged, but that the # indicates a search parameter.
and that #Dallas worked for him — Links to John’s tweet which reads “Dallas is good”
@Jamie and @Sam
said they’d like to go then too — “said” queues the system to look for recent quotes by Jamie and Sam.
I think this works for everyone — message content

Implementation of this method would obviously require a significant extension of the Twitter platform, but the basic methods already exist. With semantic fuzzy matching, it would not be impossible to search user posts by key phrases and provide the user with a choice between close matches. In the event of no matches, plain text is used.

The system would have to be paired with an interface navigation language, affording such searches as “what’s going on with Elizabeth?”, “Did John say Dallas worked for him?,” and “What are people saying about O.J. Simpson?”