Ara T Howard, long time Rubyist and partner at the Boulder Colorado based web agency, Dojo4, explains why using a static site architecture unleashes the creative forces of the agency’s front end talent.
He shares how to use Draftin and Middleman to create a collaborative authoring environment that seamlessly publishes Markdown documents to rendered HTML on BitBalloon.
Mike: Hey everybody I’m Mike Ruescher and I am here with Ara Howard from Dojo4 and this is the BitBalloon podcast where we discuss new ways of developing websites and applications using the static site architecture. So Ara How’s it going?
Ara: It’s going great. Launching some sites today.
Mike: Okay. I’ll try to stick to the point then so you can get back to launching stuff! You guys are out in Boulder, Colorado, right?
Ara: Yeah, Dojo4, we’re a creative technology agency that’s located in downtown Boulder. We’ve been working here as the agency for about five years, although the founders worked together in some fashion for a number of years before that. And so we’re really fortunate to be right in the middle of what we like to call start-up alley here in Boulder and we get to do a lot of fun stuff. Everything from website to native apps, to Rails applications, to massive like cloud infrastructure, so yeah.
Mike: Quite the range there. Sounds like you’re no strangers to building fully dynamic web properties.
Ara: No. Absolutely not. I’ve been a Ruby developer since Ruby 1.4 maybe even a little bit before then, long before rails was on the scene and you know at that point, I was building a lot of dynamic web applications for NOAA through the Co-operative Institute for Research and Sciences and we were doing — so at that point it was mainly CGI applications but also some really, really sophisticated java applications using old school MPM-CGI which is new school kids call that Server push. But yeah, I’ve been building dynamic data-driven web applications for, I’m embarrassed to say, probably more than 15 years at this point.
Mike: So, you started this Dojo4 about 5 years ago?
Ara: Yeah. At the time I became a partner in Dojo4, I had an LLC codeforpeople and a lot of people know that name from the Ruby world, it’s 200 gems, definitely way more than 150 gems in the Ruby community at this point, so that was my former consultancy and then that company and myself along with a few other individuals came together to do something a little bit bigger than just doing rails work including design and production work, copywriting and interface design.
Mike: Integrating vertically.
Ara: Yeah there you go.
Mike: Excellent. So when you guys started out, you obviously had to put up some sort of website to tell the world about who you are, and was that a static site from the beginning?
Ara: Yeah. It was actually and I’ve always been a big fan of static. To the extent that ten years ago I was using some dynamic tools like the Ruby CGI library, most people don’t know that you can run CGI programs off standard in and standard out. And I was basically developing my own static site generators. So that I could work with some of the really early Ruby templating libraries. Don’t know if anyone remembers that. We were doing a lot of template driven static site generators, at the time. Like 10 years ago before it was really in fashion. And I’ve always been a fan of that just for the obvious reason that static scales like mad. But also as a developer, I like having everything in source control, My IDE is VIM and I like just being able to work.
I believe in the power of plain text.
Static makes it possible to create architectures that scale really easily, so I’ve always had a preference for that. And when we started Dojo4 our very first website was something static. Our creative director and I had a couple versions of the site that was static, of course it was checked into Github and we went through a variety of deployment solutions. It was even running out of a box in a closet here at one point. And it was on a EC2 node we hosted on S3 at one point when that first was possible. So I’ve been deploying dynamically generated static sites for the duration of the time I’ve been working on the internet.
Mike: Then at some point though, you guys moved on to a more CMS-based solution, which actually had a database which was generating your site, not pre-rendering it, right.
Ara: Yeah, and at the time it was of the former partners of Dojo4, and we had this discussion and we really wanted to encourage people to write. I mean that was the motivation, to increase participation in the development of the website that was the impetus for moving on to a more CMS-based tooling, and so we looked at a variety of things and some of the people in the shop were experts with expression engine, of course had experience with WordPress but as developers we wanted input into having a modern framework that was simpler to deploy, easier to manage, and Github had a variety of deployment options and was more extensible, solid MVC framework. So that ruled out pretty much most of the popular CMS’s with the exception say of expression engine which was ruled out on the basis of it being semi-closed. Its not open source software. And so we ruled it out.
We ended up going with Refinery at the time which it was a nice toolkit. We rolled out a new site and it certainly worked. Certainly people who were non technical could use it, so we had that setup for a while and we noticed that people weren’t doing a significant amount of new writing. Design was limited because the people who were sort of passionate about design so on a spectrum of designers and front end developers, there was a barrier to entry. They were like, can I change a little bit of HTML, a template here and there and it’s like well yes but it depends, it just depends. Like you had to actually understand the technical stack depending on what you were trying to achieve. Say we wanted to lay the blog out in a grid and not have traditional pagination, like a design concern, you’re going to have to think about that a little bit, infinite scrolling or Oh we’ve got to write some Ajax or something like that. So we didn’t see a lot of additional writing. We didn’t see a lot of creative revisions to this site and we saw despite the fact that it was a good framework and was usually extensible, we saw almost no custom code written.
Mike: Perhaps there is even a bit of a psychological barrier to actually writing and getting stuff out there, and that’s what might have happened in your situation. I think in a lot of situations, if you have the added overhead of maybe a rails app or any sort of additional complexity around authoring then that becomes the excuse to not do it.
Ara: Absolutely and so we saw a lack of both technical and creative input into the site or innovation. Lack of technical and creative innovation and so. then we launched into our second most recent version of the website which we ditched the custom stack and we did something custom. And the reason that we did something totally custom was again, you know the thinking was. Well there was two lines of thinking. One I don’t know if you’ve read the Done manifesto but I’m a big believer in the concept that doing something makes you right, its one of the ideas there and we were basically seeing that the Rails dev, the developers were doing a majority of work.
And so the overhead of having a predetermined model structure and to be limited by even what the CMS could offer just to create a dynamically generated blog-post didn’t seem to work out. And so we developed a custom rails app and we have a CMS plugin that we’ve written that is very simple, it’s not a fully fledged CMS, it fulfills the need where you have a rails app and like hey we just need to also edit some content type, so that’s very common in rails projects.
Mike: I’ll have to check that out.
Ara: Well, its one of the few projects that’s not in the public domain. I could extract it into an engine, it’s on the to-do list. I have some hesitation around it for a variety of reasons. But in any case we use that and then we were able to achieve somethings quite easily because we were on a fully custom stack. so for example our old rails app, our deployment actually it basically when something like deploy the rails app, and then because we had a quite good configuration I had it so that content editing we used page caching, heavy heavy use of rails page caching. So that for all practical purposes the site was almost exclusively served by Apache and nginx, depending on whatever was deployed to you.
So we basically wired into the content editor invalidate the entirety of the page cache, it was a sledge hammer, but it had a beautiful property that for almost no work, the site was extremely fast, extremely durable and easy to manage. Page caching has gone out of fashion in the rails world but for content non authenticated apps, it’s absolutely unbeatable. So we were quite happy with that. That was the best incarnation of the site that we had for a long time. We were able to have a lot of authoring again, not a significant uptick but it was very easy for developers to make changes for sure. When we had a new idea, like oh we should do this customer survey thing at Christmas time or whatever. It should have add this little webhook to do whatever. We should build a tweet feed, it would be super simple and super robust to implement.
But then again something started to smell a little funny to me and during the period that we are using this on our own website we were building a lot of static sites using primarily middleman as a site generator for customers and the niche that we were filling there really was, I’ll just take a little tangent here, you know we worked for a lot of customers that were dissatisfied in particular with rails apps deployed to Heroku, or with Wordpress, because of the common litany of excuses: it’s insecure, it gets hacked all the time, it’s down every now and again, it cost too much to maintain, and so for a variety of companies it was a little challenging to get them to make the switch. But we basically were able to say to them look, if you just give up on real time editing of content, just give up on that. A funny story on that is of the bigger companies, they’re very large, a successful startup here in Boulder and they were definitely reticent to off Wordpress for their main sites, they has some reticence to going to a fully static site and like well, what if we want to make updates? Fortunately we had been working with them for a year, and we were sort of able to point out that look your organization is larger now, you have 50, 60 people, nobody just publishes directly to the blog.
You have a publishing flow which ultimately ends up in internal review outside of the system, and at the end of the day a word doc would get shipped to us. And we would report it. And this is very common, very common. Basically, for the one person shops static html works fine. And then there’s the sweet spot of like maybe two to eight people were something like WordPress for small business does allow every body to contribute. Everybody can put their plugins in, everybody can edit content, but once an organization gets bigger the invariably end up with a content publishing wordflow. You know this stuff has to go through Marketing, it needs to be approved, it needs to be scheduled for November, instead of September. And so all of that kind of goes out the window and so publishing is much more controlled and centralized, so we were able to say that look what does it matter to you when you’re giving us this content and we’re putting it in to whatever system and simultaneously they have concerns around up time. Absolutely we need our site to be fast, people forget how important speed is for SEO.
We want it to be robust, people forget what poor marketing having your website be down is, if you’re a technical company, it really makes you look like an ass if you can’t keep a website up. And so we made the switch. And their site is managed completely in Middleman, every single change by every author is in Github. We can rollback this site to any moment in time, all data, all content, seven months three hours and 2 minutes ago we know exactly what the site looks like. We would deploy it to S3, we were doing quite a bit if that about a year ago and I liked that quite a bit and I was looking over some of the clients we had done that with.
I was looking at what we had done, and then I realized and felt kind of foolish in a way that I’m like you know, our site, our rails app it really is a static site generator. We’ve moved fully paged caching at the end of the day,in fact at the end of my deploy, I could actually run wget mirror and warm the cache and at that point, other than when we’re editing, it didn’t really matter if the site was up and I thought well okay that’s neat. But it certainly is driving a plastic tack in with a 30 lb sledgehammer.
But that wasn’t the motivation to reinvent the site, so we talked for sometime about moving this site back from Rails to Middleman and making it static.
But one of the things I got hung up, and this is still an issue is that there are some issues with deploying to S3. For example we have had some issues with content negotiations, so gzipped versus not gzipped, that’s a small issue.
But I think the biggest one we have is deployments and S3 especially for our larger sites say like 1000 pages, 2000 pages - It doesn’t offer atomic deploys. So that especially when you’re doing client work, can be a little nerve wracking to push out a new version of the site and worry that your network is going to go down in the middle or that people are going to basically be experiencing a broken site during the deployment.
Now practically speaking it wasn’t a huge issue but I wasn’t comfortable, I wanted to make our site even better, I wanted fast and I wanted atomic and I wanted robust performance out of what was serving our website.
So I played with the normal permutations of, we can make it HA, we can load balance between servers and then have Capistrano based deployment, so it’s atomic, it’s HA, but are you kidding me? It take two minutes to like three minutes to like pushup a one character change, it just didn’t feel good. And that’s also very challenging to reason about.
I was telling you for the our second to last permutation we were mostly concerned with allowing developers, the people who are doing the work to be able to do the work easily in the tools that they like using. And so that was a step in the right direction. But really the people who need to be editing websites are front end engineers they’re not designers, they’re not back end developers, they’re not Rails developers.
They are people who are passionate about HTML and CSS and retina optimized images and why we want to a SVG logo and we have to use this IE hack. And that’s because the front end, just the HTML you deliver has gotten exponentially more complex in the last 2 years. Because of he proliferation of the byte sizes combined with resolutions combined with network speeds right 3G, 4G, online, offline, broadband, android phone, turn sideways, suddenly the development the ability to be creative on the front end has gotten quite technical.
And that’s where the real innovation can occur in a web and so I realized it’s those people that you really want to give those people a playground on your website, if you want to experience like the maximum creativity, those people need to be able to work quickly. and so those people they don’t really care about say SSH Key round robin, I need to deploy the three servers to make these up, oh I need to run a database migration to like get some change deployed, they don’t give a shit about this.
And nor should they.
So I went back to the drawing board and I had been looking at BitBalloon for a while, it seemed very promising: the atomic deployments, the CDN distribution which of course is something you can do on AWS if you push an S3 site out unto cloud front, but all of the sudden your deployment has really gotten complicated, and caching validations is really hard to reason about.
Mike: You wanna abstract that stuff away if you want to make simple for people.
Ara: Yeah and we can do it, back end engineers can do it, but the question is as a web agency is do I really want to spend time screwing with caching validation across a CDN for our website, it like the last thing I want to spend time on.
Mike: I think half of our job is avoiding bunny trails.
Ara: Yes exactly. And so where we’re at now our new site, I’ve been talking to Steve one of our really talented engineers and it just happened like one day, I said you know what let’s rebuild the whole site in static and about 48 hrs later we were done. We took the rails site and we designed, implemented and deployed an entirely new infrastructure that is based on BitBalloon, a webhook and the Draftin editing service, and Middleman. And so from the beginning the site is a Middleman site and it doesn’t matter what site generator you would use. You might use Docpad or there’s a variety of really great site generators but we have a site generator and all our content is checked into Github so we started there.
Here is a website, a very easy, a very well factored website but data-driven and all static entirely contained in Github. And so then we needed to move on to like how do we deploy it. And so we made the deployment we went to BitBalloon. That was not a lot of work.
We compared our Rails site being served from Apache to one being served from BitBalloon, same content. Our Google page rank jumped from a 35 to like a 88, just with no work!
Mike: That’s awesome.
Ara: Yeah, it was really beautiful. We were able to take sprockets out of the entire thing. That’s something the BitBalloon does for you. It’s sprockets as a service, we are like screw compressing images and CSS and we don’t even want to think about it also, like not our problem like why do we care about this.
Mike: Absolutely, why does everyone have to re-invent the wheel there, right.
Ara: Yeah, and I mean, sprocket’s is a good tool chain, but again I’ve spent many, many days of my life debugging asset compilation issues on developers boxes and to the extent that sometimes I’ll avoid using the tool chain for small things.
Its just not important enough, so in any case although I’ll will say its gotten much better. so we have this static website, its written in middleman, its all in github and it can deploy to bitballoon.
And so now we’re in a position where the front end guys can iterate very, very quickly. They’re just able to churn out new features. Like we had a St. Patrick Day version of the site took a few minutes to make the tweaks, deploy, great. The hosting is super robust, it’s super fast, it takes out a whole bunch of complexity. CDN invalidation, asset magnification.
So as a technologist, a CTO, I can look at it and say yes I will put my name on that, I can show that to a client and say you think you need key words or a certain CMS for SEO which of course Google ignores now. But your site is like a dog and Google cares about this, you need to make it fast so that search engines can consume it, prefer to consume it. And so I can look at the site and it’s like yeah something I’m proud of as technologist. Look how fast it is on your phone, on 3G, its blazing fast, oh and by the way its up, like I don’t have any infrastructure to host it, I don’t have boxes, I don’t pay for anything to host it, or pay for very little to host it, so I’m very happy about that.
But we lost the ability to publish and for non-technical people to publish. And that’s kind of a deal killer for some people right. So what we did, we have been using the very excellent Draftin service and I don’t know how many people are listening here have used it. Its basically a markdown editor. It’s an in browser markdown editor at first glance that’s what it is but if you dig a little deeper and the UI’s deceptively simple, it offers a lot of features, but two of them we really like for our publishing workflow, well three of them, i should say.
One: it allows you to share your draft and get feedback on people in a sort of git pull request based way. So people are able to make suggestions and alterations and the author is able to merge them in very quickly. This is all happening outside of any CMS or online site repository or anything, it’s just online service were you’re writing things and very, very good collaboration tolls and merging tools. That one feature we were using a lot before we started using it for the website.
The other feature that we use a lot, is I’m writing a lot of proposals in it, so often times I would write something, solicit feedback from my team and then I have a really nice feature called ask your pro where you just pay and you just pay a small fee 6 bucks for a professional editor, who’s automatically under and NDA will edit your draft.
I really like that because I make a lot of spelling errors, I’m a very fast writer, but I’m sloppy and it’s great for me to be able to put together a you know 200 word blog post and go you edit it. That’s 6 dollars it’s so worth my time it’s not even funny.
So I’d often times put the editor into Hemingway mode which means you cant even hit the back space key you can only write you can’t delete. So I write then press I press the button, hey editor for 6 bucks clean this up then I’ll solicit feedback from the team, and now I have something that I might post. And I was doing this when we had the rails app. And so a rails app we could post in Markdown too and I would just export it and paste it in there.
So Draftin has another killer feature, you can configure arbitrary web hooks and it can deploy content to WordPress, It can deploy content to Tumblr, FaceBook or arbitrary webhooks. And this is where our coup de grace came in we said we built a little robot, its' a teeny little webhook that sits on one of our EC2 nodes she listens to these post backs from Draftin. It’s a secure webhook so every author has a secure URL and we basically just give it to them, I’m like look all you need to do in a Draftin interface is put this URL and call it Dojo4. you can give it a name, its your Dojo4 endpoint.
So now you can use this Draftin tool which is like so much more sophisticated than any CMS editor out there in terms of managing arbitrary workflows, of review, revisions, internet planning, so on and so forth to get to develop really good content. Which is the basis of a good site, and then my two seconds with a URL and a name you can say and there’s s Webhook. So that Webhook when they hit publish, when anyone set up in Draftin hits publish, it posts to our little robot and so she catches the draft it comes in as a big ball of JSON and without getting too technical, what I do is drop it in the file system once in temp just to like make sure that I’ve captured it and then I basically spawn an import process and so that import process is actually written in our website repo and in plain English our website repo has a command line tool that knows how to import files which is the JSON, the blob JSON, the Draftin post to us, it knows how to import that and the fact that it happens to do it though obviously you can run it from the command line if you have the file. And this is basically what this little command line script does it just examines, it has a mapping of the webhook to what kind of content, so right now all of our webhooks make blog posts.
But it could be a blog posting or anything else, it’s the URL that determines this, what end point you publish to. So right now they’re all blog posts and the UID that’s in the URL also as well, lets me know what author it is, so obviously I can drop stuff on the floor if its not an author I know about, and so then I can just basically explore that into the file system into our static site repo, so we have data, and Middleman uses a data layer that’s mostly -based and we have something that’s much more sophisticated than that, its on Github, it under ahoward my github name ro standing for ‘read only objects’ and it’s a system that just meant to like manage your site content in a really super understandable directory hierarchy, its not that complicated.
But if you think how would I lay out the data with relative assets for those blog posts in a file system that what it does. It just gives you a very good interface to it. So the import of the file from, I just basically write some files and the directory to disk and it gets committed. And so then it’s in the repo, there’s notifications coming to our Campfire room and all the other notification channels like another git commit, and then the robot deploys the site and we have some email hooks so as the robot is pushing the site up it just lets the author know that we get three messages which is like hey I got your post, i am building the website and I deployed it and it’s live. That process takes a few minutes, and I have some new work that I believe will make it many times faster compiling the site, building the site, its not actually the deployment
Mike: Pulling in dependencies?
Mike: If only that’s what it meant when it’s a What You See Is What You Get.
Ara: Yes, right. And I think that something and I have explained this to clients too, it’s a real hard. the concept of content editors lowering the barrier to entry for the layman to be able to edit content, I don’t want to say it’s impossible now but that question “what do you see?” is actually pretty hard to answer right now and it’s like well, do you mean on an iPad when it’s rotated sideways or do you mean on a large screen Mac monitor and it’s like and of course it’s like a rabbit hole, and it’s like actually Jeez should that banner image even be there on the iPad, it’s real big, what if they aren’t 3G, we may not even send it down, And so your points were all taken, i think, the concept of, I think, it has got to change, its not What You See Is What You Get when you’re editing, it really needs to change, that these are the important aspects of my content. And then the system has to do something clever based on the device and the network that the user is using to consume it and that problem is getting worse faster, its not getting better faster.
Mike: Well I think there a few things I want to note here is that one is this is a perfect example of where we really believe the web is headed to: a more composable ecosystems of services. Where you use the services you need and compose them together to produce a result and this is what you’re doing here. You’re using BitBalloon for deployment and hosting you’re using EC2 to automate the process from getting to Draftin to your site generator and these parts just work together and I think that it’s really neat to see this happening for you and working so well for you.
The other thing is that going back to what you see is what you get, definitely Markdown is emerging as the standard in the industry. It finds that middle ground between making it possible for people to author and also understand that what matters is the important aspects of what you what to have on your site and that really distills it down into that and kind of removes a lot of the pain.
If you can get someone to understand and use Markdown I think you’ve really kind of have solved the problem in terms of getting a client to manage content on their site and not having to deal with issues why does this look different in my WYSIWYG editor that it looks on the site and so forth.
Ara: Yeah, I agree with you, I mean yeah on all those points and definitely we feel like we are using composable tools and Draftin for collaborative editing. For collaborative editing is a superior tool to anything available to any CMS on the market. Markdown as an intermediate format is absolutely the best format currently to store your content in. You know you really don’t want to be coupled to any complex, data formats or databases when your talking about content that part of company’s IP, that content is very important, it’s very hard to generate, you want to be able to reuse it in a variety of ways and so you want a format, you don’t want it in a propriety CMS format, you want it in something very simple that you’re going to be able to migrate through systems for 10 years, because that content, you know that represents your company knowledge base, your company marketing. I don’t know how to put an exact dollar figure on it, but it’s much higher than people realize.
That’s the hard part of websites, its generating good content. And that includes the images, It’s the images and the writing but you want those to be in a very simple importable format that’s going to be durable over time. And just case in point, like when I’m working with a new site generator actually based on Rails that I’m actually working on that’s building our site is actually take about 3 seconds with this new site generator but when I was getting the new tool working over our content, because our content is using this gem and it would be the same with the files, but because our content is using this gem ro, our content is laid out in a directory hierarchy which basically one blog post per directory as you can imagine. And then inside there, there’s one file that’s just the data attributes, attributes.yml, but the content is body.md, it’s a markdown file. very easy to edit in vim, and read and understand and then the assets are in a relative directory under that.
If I tarred up that content and there’s other content-type in there too, people and jobs and stuff like that, but if I tarred that up and gave it to any web developer, anywhere in the world, who have ever worked in any language ever and I said you need to expose this in your Go static generator or your php dynamic site, whatever, you would not even require a readme. It would be like this is all the content of all of Dojo4 right here.
Mike: Right. That’s impressive.
Ara: Yeah, and then it’s not. Ff you asked a hundred developers to lay out a directory hierarchy of content for a website, 99 of them would do it this way. So keeping it plain text and portable, that’s another, that’s also sort of the composable idea that you’re talking about right?
I should be able to take this content and do something else. Write it, script it, takes our blog and publish it as a book. Which is something done for clients for example. So that’s true and then finally just using BitBalloon to solve the asset compilation, CDN, hosting, HA, speed problem for us, I don’t even remember what you guys charged, it’s like so cheap, I’ve forgotten because It doesn’t matter to me.
Mike: We appreciate your enthusiasm on that!
Ara: Yeah you should raise your prices by the way.
Mike: That’s always good to hear. Let’s see is there anything else we want to go over here? If I want to set this up for a myself, is there a code you’ve made available? The murkiest part for me is the bot you have on EC2 is this something you guys are keeping to yourselves or is this going to be something that’s available for others to take a look at?
Ara: I haven’t released it as a very, very generic application yet. It’s a very small rack application, its only 200 lines of code and it has a good read me. They were some passwords and things well they were encrypted, but there was some data in the repo that prevented me from just saying the repo is open although it’s on my to do list at some point, I have no, my intention is to have the entire Dojo4 site and this robot have public repos, but in the short term I did publish about this workflow. It’s on the dojo4.com blog and the title of the blog is Static is the New Black. At the bottom of the article, I allowed people to download the entire rack application, I did strip out some sensitive stuff just to make it smaller and safer but I gave people the middleman app and the rack app, so that’s 98 percent of the entire system.
Ara: So yeah we’re giving it away eventually it will be public on Github but you can look at this rack app and see oh geez. I mean the webhook to catch the content from Draftin is trivial. There is a little bit of thinking. You know programming robots, having a repo with a robot that modifies the repo, is you need to think about that a little bit, its not a lot of code, it’s only a few lines. The penalty for screwing up is that things can go horribly wrong as it goes Boom!. But the beauty of it is: so what. All of our content is in Github, it’s revision controlled, it doesn’t really matter if we screw up because we can go back. Every single change.
So, I may or may not have programmed an infinite loop that did somethings to our website that I regret last week, but you know it really didn’t do anything harmful in the end. So again that’s the real beauty of aggressive caching right or having a static website is that having your website be up and what’s available to the public is entirely decoupled from any of these details. It just doesn’t matter if our whole publishing workflow is exploded or we’re doing it by hand today, it makes no difference. So for me as a developer it’s also liberating. I have no fear to try new things, I can’t take the site down by screwing with our publishing work flow. They’re independent concepts.
Mike: You mentioned already some ideas for ways that you could repurpose content for example generating a book. Is there any other things you see on the horizon in terms of how you plan to use this with future clients or existing clients that you have?
Ara: I think the thing that I realized is that ultimate system that we would build, Draftin’s really close and think that very, very appropriate say for blogging and other things. But there are some limitations as in if you share something you’re going to publish with me as you’re writing it, we can both see it, if you publish it then it’s checked into the repo and everyone can make edits to it. And then of course when its published everyone can see it. But other than the repository I don’t say have a view automatically into every draft, every person is working on if they haven’t solicited me for input.
Now our organization is only 15 people but if you use an approach like this for an organization of a hundred people, that may not cut it and so I see Draftin and I’m realizing that in the old domain system you still may have I guess what’s called a centralized CMS. In other words there’s a Rails app and you log in to it and you can use the tools there and that can publish content. That same rails app may have content that Draftin can consume. Right, you like have this simple web interface or any other reasons, yes Draftin is an inlet too, Oh by the way so is email, right, we have lots of scripts that listen to email channels so for me to write well I won’t go into what we do with those, but for me to modify one of those, scripts that we have that listens on an inbox one of out company inboxes and say yeah actually if you email to blog at dojo4.com too, it does the same thing.
So I think the fundamental architecture is firmly decoupled, authoring is decoupled from publishing is decoupled from revision control is decoupled from hosting.
So that’s perfect but I do see maybe developing more of a centralized application to have more total knowledge of the system. For example an administrative person could go in and click a button and generate a Webhook URL for a new employee for example, so here’s one now you can use this to publish on Draft, which right now is, well we do it from the command line but its not exposed to non technical people.
So i really see augmenting it more than any thing else is what I see in the new future, augmenting and optimizing because right now our workflow is good. The price we pay for having you know a site that is screaming fast, simple to manage and close to a 100 percent up-time is several minutes from hitting the publish button to seeing it. I think you know if we can get that down thats fine for us technologists, I think it might make some end users, it might make then uncomfortable.
I mean it just depends on how sophisticated they are because you have a similar lag if you’re using any CMS pretty much you can see, a kind of a lag. But I think getting the whole build and deploy site go down you know even 15 seconds that something you could easily explain to a client, yeah it take 15 to 20 secs before, after you hit publish a bunch of bots churn away and now your site in unbelievably fast. And we guarantee that it will be up, that’s a totally reasonable trade-off. So yes optimizing and augmenting, I think are the next things but I haven’t had more creative thoughts than that at this moment
Mike: Yeah that makes a lot of sense. So wrapping this up, what you just mentioned to me, it just reminds me of conversation I had a few months ago with Kin Lane, the API Evangelist, he’s also really big on a sort of git based markdown authoring workflow. And he’s got a huge empire of content that he does entirely through this kind of process. I can put you in touch with him, you guys might have a really interesting conversation about what you’re talking about, the orchestration of multiple authors and this kind of publishing flow.
Ara: Yeah. I’m really interested in that because, I think it’s important for people that really care about their content or in large organizations where the curation is so important and it’s not served at all in the web publishing marketing place right now by any major CMS.
Mike: Yes, I think there is a real opportunity there and you guys are making some real badass inroads into it. So thanks a lot Ara, I really appreciate you time and for those of you listening, definitely check out the blogpost at the dojo4.com blog Static is the New Black.