Today, most open source network flow tools lack a flexible and easy to use interface. Using Logstash’s built-in netflow codec, Kibana’s great looking and powerful web interface, and the flexibility of Elastic, you can build a tool that rivals commercial flow-collecting products. Continue reading
It’s been almost a month since we released Calypso and the response has been great from the community. For those following the project more closely, we’ll be publishing summaries on new developments, focusing on framework-level improvements, new components, and the tools contributors have to work with.
Making Calypso more welcoming for developers and designers
If you install Calypso locally and point your browser to
calypso.localhost:3000/devdocs/welcome we have a new developer flow that introduces you to our documentation. You can access the docs anytime from the environment badge in the lower left corner, which also highlights the git branch you are in:
- Upgraded to Node v4 and React 0.14.
- Started implementing Redux, a state container solution to manage data flow in the application. If you are interested in this, we are gradually moving our different data modules to Redux.
- We refined and documented our approach to components.
- Began exploring how pluggable modules could work in Calypso.
- Continued migration to use svg icons everywhere instead of the old icon font. We added a few new gridicons as well.
New components and updates
Components are the building blocks of the Calypso UI. We constantly refine them and build new ones, from simple user interface ones to those carrying more complex functionality. This allows us to craft interfaces that are consistent and rich. You can check out all of these if you go to
calypso.localhost:3000/devdocs/design, our live components gallery. These are some of the updates we did this month.
We added a borderless variation for one of our most used components.
Added a compact variation.
A utility component, primarily meant for setting up a poller interface wrapping another component.
A dropdown component for selecting a site, which includes instant search, handling of private sites.
A component that renders other mocked components with a faded effect to illustrate a section when for some reasons the user cannot access it.
Consolidated Notices into a single component in components/notice. Also added a new compact variation with flex-box magic for narrow layouts:
The core component to display a site-card now support a
homeLink prop which turns it into a link to the homepage of the site and renders the following icon on hover:
Component used to render individual post items. Now supports a “selected” prop to highlight a single draft in a list. (Used in the editor.)
Now also support custom icons.
Stay tuned to this blog for upcoming Calypso news and updates.
A little over a year and a half ago, we had a dramatic rethink of the technologies and development workflows for building with WordPress.
Our existing codebase and workflows had served us well, but ten years of legacy was beginning to seriously hinder us from building the modern, fast, and mobile-friendly experiences that our users expect. It seemed like collaboration between developers and designers was not firing on all cylinders. So we asked ourselves the question:
“What would WordPress.com look like if we were to start building it today?”
A New Beginning: Prototyping and Iterating
We’d asked ourselves this question before, and had our fair share of initiatives that didn’t result in useful change. Looking back, we were able to pinpoint our biggest mistakes: we’d been starting with a muddy vision, and were trying to solve an ill-defined problem. These insights really helped us change our approach.
Calypso, the codename for this new WordPress admin interface project, started differently. To present a clear vision, we built an aspirational HTML/CSS design prototype — based on clearly defined product goals — that allowed us to imagine what a new WordPress.com could look like when complete. We knew it would change over time as we launched parts to our users, but the vision provided all of Automattic with something to aim for and get excited about.
One great change came out of building an early design prototype: improved collaboration using GitHub. Calypso prototyping was done collaboratively between a handful of designers in GitHub; although many of us had long used GitHub for personal projects it was relatively new for internal projects, which historically used Trac for most project management and bug tracking. Using GitHub helped us see how much easier internal collaboration could be, and how to allow for much greater feedback on individual work being done.
What started as a team of seven people working on Calypso quickly spread to a cross-section of teams with ten, then 14, then 20 Automatticians actively working in the Calypso codebase. Two months after the launch of the first Calypso-powered feature on WordPress.com, we had 40 contributors working on Calypso across five different teams. We iterated over the next year with the “release early, release often” Automattic mindset, launching 40 distinct Calypso-powered features on WordPress.com with over 100 individual contributors.
Open Sourcing Calypso, the Power Behind WordPress.com
One of our Calypso developer hangouts in progress, and Team IO, who built the Calypso editor, at our all-company Grand Meetup in October.
We’re proud to be able to open source all of the hard work we’ve put in, and to continue to build on the product in an open way. You can read more about opening up Calypso development on our CEO Matt Mullenweg’s site.
Over the next few months, we’ll publish more in-depth posts exploring the technicals and workflows behind Calypso: how we manage our own unique GitHub flows, how we’ve used other popular open source libraries like React and concepts like Flux, and our experiences bundling and launching native app clients. Keep an eye out for those by following this blog (in the bottom right), and in the meantime, check out the active Calypso codebase as we continue to iterate on it.
Calypso Project Lead
Several years ago, WordPress.com introduced oEmbed provider support to allow posts on WordPress.com-hosted blogs to be embedded anywhere that supported oEmbed. WordPress 4.4, due out in December, will bring oEmbed provider support to the wider WordPress world.
One week from today, on October 2, the WordPress.com team will be switching our oEmbed format to match the global WordPress format. The oEmbed spec allows for arbitrary changes in the HTML being returned, but since this is a significant change we wanted to give everyone ample lead time.
We understand that not everyone is comfortable with embedding arbitrary scripts on their page. If you wish, you may strip the script tag and provide the same functionality using the script from the development plugin. If you choose this method, please keep in mind that this script is still under development, and will likely change between now and WordPress 4.4’s release.
In order to test the new embeds, simply add the query string ?newembed=true to the URL of any post hosted on WordPress.com, like so. Similarly, you can get the output from our oEmbed endpoint by adding &newembed=true to the end of the request. We’re still working on adding support for this new style of embed to the WordPress.com post editor, but you can test it on your own WordPress install using the feature plugin.
If you run into any issues or have any questions, please post them in the comments below!
Update: September 25, 2015 16:00 UTC — We are temporarily reverting this change. Please see the comment below. We’ll update this post when the new oEmbed is re-enabled.
Every day, millions of people connect with ideas, photos, and other content on WordPress.com. Here at Automattic, we take pride in enabling this interaction, and continually strive to make the WordPress.com platform better for users.
Our data science team examines these user interactions, and aims to develop our insights into user facing features and tools. With this challenge, we decided to open up some of our work and share with the community some of the questions we are excited about.
On our platform, and across the Web, the question of social reciprocity is one of the most interesting. How does platform design, user content, and social activity combine and affect user engagement?
We are running this visualization challenge on the Databits.io platform, where we’re inviting anyone who’s obsessed with data like we are to come up with some interesting visualizations of the following scenarios. We’re offering a $1,000 prize for the best one!
Two ideas we’d love to see explored are
- User-to-user social reciprocity. The provided data is sufficiently rich to explore the dynamics of user-to-user social interactions. Are there compelling stories we can tell about how individual users react to other users’ actions on the platform, temporally? How does blog posting and the kind of blogging content enter the picture?
- User-to-community social reciprocity. There are actions that users send to the broader WordPress community and also records of the community generating social interactions on the users’ blogs. On the scale of user to community interaction, are there patterns that can help understand social reciprocity? Does the interaction depend on blog posting? What are the temporal dynamics?
Read more about the data, the challenge, and the prizes being offered for the best visualizations over at Databits.io.
If you love data like we do, consider joining our team! We’re currently hiring Data Wranglers.
We’re happy to announce that the Photon image service now offers seamless support for the WebP image format. This new feature provides size reductions of up to 34% for served images compared to a JPEG of an equivalent visual quality level. One thing to keep in mind, though: WebP isn’t currently supported by all browsers (see the WebP FAQ for more details).
The trick in serving a format that isn’t universally supported is to auto-detect which browsers do support it, a process that can become clunky and unwieldy. We found a simple solution, however, in the Accept header, which is sent along with every image request. In this header the browser specifies whether it supports the WebP image format. Consequently, when our regionally distributed Photon CDN servers analyze the headers, the service is able to detect and serve the best image format for each browser request that comes in from its local cache.
We should note that by default, Photon is compressing the WebP images at a high quality setting. If you want to get the most out of this new feature, utilizing the quality parameter will yield the best results.