By Deane Barker on April 17, 2014
I talk at a fair amount of conferences. Over the years, I’ve taken notes on how to do it well (this pre-supposes that I do it well, which is very much up for debate). I figured I’d share these notes.
Now, understand that I give a very specific type of conference presentation, which is 30-50 minutes and always based around a presentation deck (a Power Point). This might not fit for everyone. Some of you might be doing a short speech unsupported by any visuals. If so, pick and choose from the sections below.
Also, I don’t offer this list as hard-and-fast rules, nor do I think it’s the only way to do it. This is simply what works for me. I concede that other people may have entirely different ways of doing it.
Here are my notes, edited slightly to make for a better blog post. If you’re staring down a conference presentation, I hope they help you. (And, in the true spirit of PowerPoint, these are in the form of bullet points, because that’s how I wrote them down originally.)
Questions to Ask the Organizers
The answers to these questions will help you, either explicitly or implicitly. The idea here is that it’s good to get as much background info as you can, because whether you’re aware of it or not, it will influence your talk as you put it together.
- How long do you have to speak?
Do they expect a Q & A period?
Where is the venue? What is its layout? A theater? A classroom? A conference room? (If you can visit the venue beforehand, or see pictures of it, do that. It really helps to be able to visualize the room when you’re rehearsing. Things that might work in one type of room will fail completely in another.)
Can you have a deck?
How many people are in attendance?
What events are before and after your talk? Another talk? Which one? Food? Going home?
What is the audience members’ relationship to the topic? How knowledgeable are they? Are they seasoned conference attendees, or is this rare for them?
Have they paid money to be there?
What is their expectation of learning? What do they hope to come away with?
How is your talk being advertised or promoted? What is the organizer promising – implicitly or explicitly – to attendees?
What is the tone of the talk?
Tutorial: insert tab X into slot Y
Informational: this is information about topic X you might not know
Conceptual: this is a new way of looking at or thinking about X
Narrative/case study: this is something we did in situation X
What is the scope of what you want them to learn? Are you trying to teach them something incremental, or something revolutionary? Do you want then to nod their heads and say “that’s some useful information I can use,” or are you shooting for “wow, that was mind-blowing!” The latter is riskier – it’s awesome when it works, a disaster when it doesn’t.
What is the point of your deck? Is it the focus of your talk — screencaps or something you will be talking about directly, or is it decoration and mood-setting?
What are the technical parameters? Will you be able to use your own laptop? How big is the screen? Will you have a monitor where you can see your deck as you’re giving it? Will you have a remote mouse (hint: bring your own).
Planning Your Talk
Start early. I know you don’t want to – it’s so much easier to avoid doing it because it can be scary and actually doing it brings you face-to-face with that fear. But the fear isn’t going to go away, it’s just going to get worse with time, so face up to it early.
Give yourself enough prep time. The rule of thumb is that you need one hour of prep for every minute of presentation time. So a 50-minute talk will take over a full-time week of work to put together. This, of course, varies greatly, and you may have a full-fleshed out talk in your head, ready-to-go. But, in general, understand that it’s going to take more time than you think it will.
Write down, in a couple bullet points, the things you want the audience members to come away with. In a perfect world, this is what they learned – this is the future state you want them to get to. These points will guide you while putting together the entire thing. You can “test” your talk against these points.
Write down the major talking points to support those learning points and put them in order – “to tell this story, I need to talk about X, then Y, then Z.” This divides your talk up into sections, which is important. Talks need to progress like a story – there needs to be a build-up, a center section, then a conclusion. A movie separates these with “plot points.” You don’t have plot points; you have section transitions.
Incrementally embellish each section. Treat it as a mini-talk by itself – “to tell this story (section), I need to talk about X, then Y, then Z.”
Don’t edit too much when putting this together. Go nuts. Pretend you have all the time in the world and make it as long as you want. Rehearsal is when you start cutting the thing down, and it’s better to start with too much information than too little.
Don’t be surprised if the content of your talk changes considerably through this process. Not only the specifics, but the entire nature and message. This sounds weird, but as you say things out loud and create slides to illustrate it, this has a way of catalyzing things in your own head. You don’t truly understand something until you have to explain it, and the process of explaining it will often make you think differently about it. (See “Rubber Duck Debugging.”) There have been several times when I was mid-way through rehearsals and suddenly realized, “I’ve been thinking about this all wrong…” or “My main point is not that important after all. Rather, this smaller point is really want I should be teaching them…” If this happens, don’t be scared – it’s a gift.
Preparing Your Deck
Transfer your outline to PowerPoint, or whatever. Most all of my talks are very presentation-based, which I realize isn’t true for everyone. But when I’m prepping a deck, I put my outline in Power Point, then start developing there.
For goodness sakes, understand how the software works. If you’re using PowerPoint, get a book and do some remedial PowerPoint training. This is stressful enough — don’t make it worse by not understanding what you’re doing.
A practical note: put the file in Dropbox immediately. You don’t want to lose it, and if someone goes wrong, you can retrieve it from Dropbox from any computer. There are several times when I’ve had to download a deck from Dropbox onto the presentation computer at the last minute. (Once, in Lisbon, I actually made a change 15 seconds before I went on, hoping that it replicated fast enough to beat me to the podium. It did.)
Do your title slide and your transitional slides right away, so you have a framework of the talk to work with. You have your sections set now, so you can concentrate on supporting them individually and telling the story around the transitions between sections. Also do the last slide — it should always be your contact information. So you should have the beginning, section headings, and final slide done first, which gives you a framework to embellish.
Don’t worry about design too much. If your slides need a theme, and if you know how to work your presentation software, you can apply it towards the end. (The current trend is away from design – the plainer the better these days, it seems.)
Do not pay attention to any guidelines about how long to talk over a slide. I’ve spent five minutes talking about a slide. I’ve also spent five seconds. I’ll often have a sequence of five slides that I rip through in 15 seconds. It’s not important – your talk matters more than the slides. They are there to support what you’re saying.
Rehearsing Your Talk
Rehearse out loud, by yourself, to an empty room. Yes, you’ll feel stupid. Tough — better to feel stupid by yourself than in front of a group.
Rehearse the entire talk at least 10 times. Yes, that is a lot.
Get a remote clicker. Walk around. Gesture. If your dog doesn’t look at you funny at least once every rehearsal, you’re not moving enough.
Rehearsals have two different flavors:
Exploratory: this is a loose run through, when you stop and adjust slides, change things, etc. You can stop in the middle and edit.
For Time: keep going through, no matter what. This is how you’re going to determine if you’re within the time boundaries.
Don’t always rehearse from the beginning. The goal is to be able to pick up at at any point in the talk and carry through to the finish. So, in addition to doing the entire thing, start ¼ of the way through, ½ of the way through, right at the end, pick a random slide and start from there, etc. If you start from the beginning all the time, then the beginning gets a lot of focus, and the latter part of the talk doesn’t get your full rehearsal attention.
Try to get Presenter View (a PowerPoint thing; Keynote probably has something similar) — you should be able to see the upcoming slide on a separate monitor at all times, with your notes if possible. If not, print the presentation notes out before hand. (Though, honestly, if you have to refer to your notes at all, you probably didn’t rehearse enough.)
If a slide doesn’t feel right, it probably isn’t. If you’re tripping over a slide, and it just doesn’t sound right, get rid of it — either drop it, or combine it with something else. So long as you have enough time before you have to talk, don’t be afraid to do major surgery. Slides that sound wrong, probably are wrong.
If you’re using notes, don’t write them as if you’re going to read them verbatim. Write bullet points that will just jar your memory of the points you need to cover.
Concentrate on your last section. This is the payoff, and too many times, people rehearse solely from the beginning so by the last section, they’re just trying to get done. Rehearse the last section by itself multiple times.
Giving The Actual Talk
Show up early, and make sure AV is fine. Get your presentation up on the screen before anyone shows up, and run through it quickly to make sure it looks right. You do not want surprises (“Where is my custom font?!?!”) right before you talk.
Have a remote clicker. Always. Podiums suck.
The goal is to have the talk feel conversational, not formal. Meet as many people as you can before the talk. As the room fills up, go introduce yourself and talk to people. Your goal is to make them feel that they’re in this talk with you, not that you’re giving it and they’re receiving it (even though that’s exactly what’s happening).
If you can, start with some comment about the event or something that just occurred: “I was just talking to Mark in the hall…” This sets people at ease and takes you immediately off-script, so it sets expectations on the conversational tone of what follows.
Don’t read from the presentation. This sucks for a lot of reasons, but mainly because you’re setting yourself up to be super-rehearsed, and if you have to ad lib, it becomes totally obvious that you’re off-script. You should sound off-script all the time.
Be explicit about the section transitions. “Okay, so I’ve just explained what X was, now I’m going to talk about why X is important.” The audience wants this – they want to know that they’re moving steadily through the talk. They want to mentally organize the content: “What did I learn in that last section? I need to store that away, because this is a new section with a new thing to learn.”
Try not to be nervous. I know this sounds like a ridiculous platitude, but here’s why it’s important: if you’re nervous, the audience will be nervous too. They’ll be scared for you, and they’ll subconsciously resent you for it. If you’re relaxed and having a good time, the audience will be too. Remember this: they want to like you. They do not want to see you fail. If you make them feel awkward, it’s harder for them to like you.
If you think of an anecdote, tell it. Remember, you’re not on a strict script here. Feel free to weave in and out of your rehearsed outline. I don’t think I’ve gotten through a single talk where I didn’t extemporaneously say something that I never rehearsed.
Gesture at the screen. Point at stuff, if appropriate. Look at the screen yourself. You want the audience to feel like this is something you’re looking at together, not that it’s just background information.
Last slide is contact information. Invite people to contact you with questions, or if they want to talk about anything you presented. It has practical value, and it’s a nice, clear way to signal that the talk is done. The audience wants to know when to clap, and they’ll feel comfortable with an explicit cue.
If you want some more good tips, take a look at this: 11 Top Tips for a Successful Technical Presentation. In particular, read the comments there – lots of great stuff submitted in the comments. It’s also worth noting that Scott Hanselman is the presenting style that I really try to emulate: he’s so wonderfully relaxed when he talks that you feel like you’re in it with him, rather than being lectured to.
If I could replicate one talk (in vibe and style, not so much content), it would be this one: It’s not what you read, it’s what you ignore. That’s Scott at WebStock 2012 in New Zealand. It’s fantastic.
It helps that Scott has spoken at my company, sitting at my breakroom table. It’s easy to like someone when they do that for you.
By Deane Barker on April 16, 2014
In content management, “archiving” is a pretty common word. Systems allow for “archiving,” or there are “archive” buttons on the interface, “managing content archiving” is a bullet in a job description, etc.
But there’s no accepted definition for it. What does it mean, exactly?
I appears to mean any one of the following:
- Move it from a common place of viewing to a less common place (but keep it available to the public)
- Remove it from public view, but keep it available for editors (presumably to “unarchive” it at some time?)
- Move it somewhere else in the admin interface where people won’t trip over it
- Move it to a different storage mechanism, perhaps near-line or off-line storage
- Delete it, but not really (so it can be recovered)
Different systems have different ways of defining it.
I posted this question to the Content Management Professionals group on LinkedIn (it’s private, so no link – unless you’re a member, you can’t view it anyway). Here are a smattering of answers.
- Archiving keeps the information available to content managers in case of any legal/ compliance issues that may arise. […] when you delete records you lose that “institutional memory” which is a lot more valuable than most people realize. Once the “archived” content satisfies your firm’s record retention policy, you can then delete it.
- […] we first began “archiving” in the late 1990s-early 2000s on websites where we had little control over how the CMS displayed content. We “archived” something by removing it from regular view [but it would still be available to search], and then, a few years later, we got a REALLY advanced CMS and we could “archive” by removing it from the production site but leaving it in the system for managers in case it was needed for audit purposes, etc.
- As a former archivist, I can tell you that the profession as a whole winces when they see the word ‘archiving’ […] In my present role, I move files out of general circulation into an ‘archive’ area within my CMS – they are no longer visible to most users, and we do worry about traditional archival things like records retention once we move them there. That said, in previous roles the ‘archive’ has referred to things like moving previous feature stories off the main page (back when that involved hand-coding a flat HTML file to point to all the older files), and elsewhere it has had that more ‘locked away’ meaning.
- From an operational point of view one could argue: Everything that is currently not in use in day-to-day business, but may be needed later for whatever reason is to be archived.
- In our system we do try to make a distinction between archives that are still publicly available and archives that are not. The former is “Archive” while the latter adds the modifier “Archive and Expire.” This latter option signifies that the content is “expired” from the site. From the perspective of the visitor, it’s as good as deleted, yet the authoring / managing team still retains the data for record keeping.
- To me the ‘standard’ definition for archiving content is allowing it to be accessible via search, while no longer remaining prominent (if navigable at all) on a user’s website.
- […] taking it out of the CMS in order to keep it for audit reasons and the like […]
- Archiving is purely and simply the act of preservation. Access, purpose and use are details that affect consumption of the archive.
- I always considered archiving a method to reduce the impact content has on the system(s) usability; for instance with regards to searchability, performance, but not in the least user-friendliness (for lack of a better word)
- On a number of projects I’ve seen “Soft Delete” used to describe the state in which content has been effectively removed from the system, but can be restored in an emergency. Archiving, in my mind, implies recognized long-term value, rather than a CYA ability to restore.
In seems that “archiving” is a very fluid term, and one that means whatever the organization defines it to mean.
By Deane Barker on April 7, 2014
I love content. I love modeling it, storing it, managing it, organizing it, searching it, and delivering it.
Why do I love this? I’ve spent a lot of time trying to figure that out. This is my best attempt, and I apologize in advance if it’s overly personal or dramatic.
Content is beautiful. It has a purity to it. It has a soul — done correctly, content is information in a perfectly accessible wrapper, waiting to be consumed and used for some purpose. It’s potential energy, perpetually standing by, ready to be unleashed.
There’s incredible beauty in that, full stop.
But, even more importantly, content is the genesis of action, education, and change. Content informs. People come away from good content with more understanding and perspective about issues that affect them. Content enables them to consider a situation, question, or decision based on clear information and then act with purpose and clarity.
So, content is core to teaching. And there is joy in helping someone understand. There is an amazing feeling when someone finds something they were looking for and finds a clarity they were missing. That’s a gift to that person. More than that – it’s a gift to the world. We are better as a human race because of this moment. Moments like this move us all forward.
Our society depends on continual progress. The information in content represents that progress. The accumulation of information is how we get better as a species. It’s why we have advances in medicine and science and history. It’s why movements start and governments fall. A population with accurate information is in a better position than a population without it.
You know that feeling when you type something into Google — no matter how obscure — and you see that someone has searched for it before? Content provides that connection. The fact that content for Topic X exists means that someone else had the same problem and also needed Topic X. You are not alone. Content unites.
The search for information is a cry for help. No matter how inconsequential, it is someone looking to improve their circumstances by educating themselves.
The content manager is a matchmaker. The world is looking for content, and content is waiting to be found. The content manager is the person who brokers that meeting. The world is better when this happens.
I want to be there for that. I want to be the silent thing lurking in the background that someone thanks when they find what they’re looking for. I want to be that source of happiness for them, however many layers removed, however faintly understood and acknowledged.
I am driven by the vision of people finding what they’re looking for, experiencing that happiness, educating themselves, and making a better decision sometime in the future because of it.
You don’t create content for yourself, you create it to be consumed. By the same token, you don’t manage content for yourself, you manage content to make it easier for someone else to consume it. Content is a service to others. It is a service to the world.
I believe that the management of content is honorable. Managing content makes the world a better place.
When you manage content, you are a gear in a larger machine. You are the volunteer passing sandbags down the line. You are bridging the gap between those who create and those who consume.
In a perfect world, you are unnoticed. You exist in service of the content, and your performance is measured strictly in how well you allow the soul of the content tor be found, understood, and used by the consumer. And in some small way, your performance in this role makes the world a better place.
This is the role I gladly accept.
This is why I love to manage content.
By Deane Barker on March 31, 2014
One of the problems with working in digital is that we tend to think we invented everything. We sit around and imagine we’re breaking amazing new ground, when we’re often just retreading ground that was broken long before.
Consider the much-ballyhooed discipline of “content modeling” (a phrase which I admittedly use freely). This used to be called “data modeling.” I wrote a sidebar for Sara WB’s book where I essentially said the same:
Many of the challenges you find in content modeling are basic data modeling problems, and the relational database crowd solved those decades ago: Don’t duplicate data. Tend toward atomicity—small particles of content. Compose complex objects by combining simpler objects. […] None of this is new, but it might be a new way of thinking for you.
What’s different now is just that you don’t need a database designer to do this – you can do it in your own, humble CMS, without help. So, old problem, just a new solution. But, again, we tend to think we’re changing the world, when we’re really just re-solving problems which have largely been solved, or finding different ways to do things and thinking that this makes it a new thing.
This is never more true than in the information architecture space. “Information architecture” is a great label, but it’s one that has gone by less glamorous terms for a long time: “library science” and “cataloguing” and “classification.” I imagine some people think “taxonomy” is a purely digital term (or even the funny made-up name for a Drupal module).
What I don’t see much of in this space is people reading the classics – going back to the basics of how this discipline has been done for centuries.
- How many people have heard of S. R. Ranganathan? He was an Indian mathematician who essentially invented faceted classification back in the 1920s.
- How about Henry E. Bliss and his seven principles of classification?
- And the oh-so-pedestrian Dewey Decimal System? There was a guy, Melvil Dewey. He was writing about classification back in the late 1800s.
- Back in the 1700s, Swedish scientist Carl Linnaeus just might have invented taxonomic classification when completed the humble feat of putting all the plants and animals in order.
Yes, these people are long-dead, but there’s some great reading there. If you’re interested in IA, I defy you not to be fascinated by Ranganathan’s “colon classification” system, or his “original” facets: PMEST (his idea of the “personality” of an object is pretty fantastic).
It’s also interesting to see the historical emphasis on labeling – they didn’t have computers that could slice-and-dice facets back then, so they had to label, and there was a science for coming up with the “category number” for any combination of facets. (Put another way: you don’t know how good you have these days…)
I’m going to recommend two books here:
- The Accidental Taxonomist
by Heather Hedden
This is a masterpiece, that will make you understand that there is an enormous body of work behind taxonomy and indexing that predates the Internet by decades, if not centuries. Heather Hedden will make you understand that the problems of IA are not new – book indexers have been struggling with them ever since Alexandria or Gutenberg. You need to understand the basic concepts of terms, the concept of broader and narrower, authority files, related terms, etc. (If you have Drupal experience, you will come away from this book with a new-found understand and appreciation for Drupal’s taxonomy module.)
- Classification Made Simple
by Eric Hunter
This is a relatively short textbook which will give some perspective on the historical basis for how we organize things. Ranganathan and Bliss are covered extensively, and you’ll understand the comparative pros and cons of facted vs. enumerative classification schemes, and how you can synthesize properties into notations to almost get the best of both worlds.
For giggles, read the footnotes and indexes in those two books. It’s humbling. I quickly came to realize that I didn’t know jack squat, and the Dunning-Kruger Effect slammed into me like a dump truck.
(To make it worse, spend five minutes skimming George Lakoff’s “Women, Fire, and Dangerous Things,” and take a second to appreciate how much research has gone into the science of mental classification, which has been a thing since humans have existed.)
Now, don’t misunderstand me – I’m not saying that we don’t know anything. Furthermore, I’m not saying that the Internet doesn’t bring about some very unique aspects to information architecture. We are doing some neat stuff, sure, and we’re expanding this discipline in some important ways based on the current environment in which we exist.
But what I am saying is that 90% of the ground we’re “breaking” has already been broken. And if we took a second to look, we’d understand that we’re really just standing on the shoulders of giants.
More than that: if you really love information architecture, go learn some history. For me, reading about guys like Ranganathan isn’t just educational, it’s…fun. It’s thrilling. It’s fulfilling.
The bottom line: we are continuing an amazing legacy, and knowing the long, dusty road that has led up to where you are walking right now will make you appreciate your discipline so much more.
Put another way, when you finally scale the peak of your discipline and reach the summit, don’t be surprised if you find a bunch of librarians who have been sitting there for years.
By Deane Barker on March 26, 2014
Why your previous developer was terrible: When a new developer comes onto a project, they often find a bunch of stuff to change right away and seem to be hyper-productive right out of the gate. It’s a matter of fresh perspective, and the ability to view the project with the perspective of the current moment in time, without understanding that the application was development in many moments in time, each with their own idiosyncrasies and variables.
It’s what I call the “curse of the present.” When you, as a developer, look at the choices used to build a particular application, you’re blown away at the poor decisions made at every turn. “Why, oh why, is this built with Rails when Node.js would be so much better?” or “how could the previous developer not have forseen that the database would need referential integrity when they chose MongoDB?”
But what you may not realize is that you are seeing the application as it exists today. When the previous developer (or team) had to develop it, they had to deal with a LOT of unknowns. They had to make many decisions under a cloak of opacity. You are cursed with the knowledge of the present, so the system seems like a hackjob of bad decisions.
So much truth here.
By Deane Barker on March 22, 2014
Synchronous communication is over-rated. By this, I mean the concept of talking to someone face-to-face, or over-the-phone in real-time.
I’m not saying this communication doesn’t have some unique properties, but in a lot of cases, it’s not what you really need. Rather, you need asynchronous communication, where one party says something but doesn’t wait around for an answer. When the other party does respond, the conversation continues.
I wrote about this almost 10 years ago when I explained Why Email is Better Than the Telephone. I said:
A lot of interactions are, by nature, segmented. In a lot of conversions with someone, you need to check with someone else about something, research something, wait for something to happen, etc. A lot of phone calls are ended because someone “offline” has to occur before they continue. This fits in perfectly with email.
And this is still true.
Real-time communication introduces lots of non-communication factors that often confuse the issue at hand. You’re trying to debate a larger problem, but you keep get distracted by the other conversant’s annoying tie and the Southern accent that drives you nuts.
Additionally, you often don’t think clearly on the spur-of-the moment. Ever had a debate about something that you “won” an hour later when you were thinking up what you should have said in the car on the way home?
Even if you’re great on-the-spot, perhaps you need some time to research something. You’re not an encyclopedia, and an off-the-cuff exchange gives you no time to make sure you’re know what you’re talking about.
When my wife and I were dating, we were full of drama, as most young people are. Thankfully, we learned a constructive way to argue – we would call each other and leave messages on each other’s answering machine. This gave us time to absorb the other person’s response, think about it, determine an appropriate response, rehearse it a bit, then deliver it.
(I still remember the time I answered the phone to hear Annie say, awkwardly, “Um…I was calling for your answering machine…”).
There’s still a category of people who eschew email and prefer the phone. They see this as folksy, good ‘ol common sense – “Why do that new fangled stuff, when the phone still works fine?” Or they view it in terms of human relations – “We’re too disconnected these days, so it’s much better just to walk into someone’s office.” (Most of these people enjoy being contrarian, and a lot of them consider this part of their personal brand.)
These sentiments may be true in many cases, but not in all. There are certain communications and interactions and patterns when a real-time, face-to-face conversation is exactly the wrong thing and will damage the exchange more than help it.
- When the topic is deeply complicated and requires multiple antecedent understandings before solving the core problem.
- When many, many participants are involved in vary degrees of depth – some deeply, some lurking on the edges.
- When the topic is vague and exploratory and relies on many sources of information external to the conversation participants. (How many meetings have you had that lasted 30 seconds before you realized you didn’t have all the information you needed and would have to get that before you could talk more…)
- When one or more of the participants are lacking in social skills – they might be quick to anger, slow to understand on the spot, too quiet to be understood, or any combination of those.
- When the topic is long-running. Some topics start as the recording of an event, and when that event happens again, the conversation restarts.
- When the topic needs to be recorded, either for historical value, or so others can join the conversation later and read the history.
I always remember a project manager at a company I worked out. I couldn’t stand this woman, and I had a hard time talking to her about anything (in retrospect, however, she was a very talented PM).
Whenever would send her an email, my phone would ring immediately. I had to resist the urge to yell into the phone “I sent you an email exactly because I didn’t want to talk to you!!”
Maybe I was just a jerk, but even then I was having trouble understanding the desire for some people to always talk in real-time.
By Deane Barker on March 19, 2014
When writing about the white paper I wrote for Movable Type, I suddenly realized that I failed to post this, which is the video of the talk I did for the Movable Type Idea Exchange in NYC last fall.
This is a recap of the talk I have at Drupalcon in Portland in May 2013. Here’s the video for that. You can pick which one you like better – Movable Type has me, and Drupalcon just has the audio, but has a better view of the slides.
By Deane Barker on March 18, 2014
Late last year, I spoke at the Movable Type Idea Exchange. I was thrilled to do this because I have a long history with Movable Type – this blog ran on it for almost a decade, and I was huge in the MT community back in the early 2000s.
After the conference, sitting around over coffee with the MT guys, I pitched the idea of using MT as a decoupled CMS to manage the content of otherwise transactional applications.
Consider online banking, for instance – that’s a big, transactional system, but it still has content that has to be managed: error messages, help text, marketing pages, etc. How do you manage that without dropping a coupled CMS on top of it?
MT loved the idea and asked me to write some code and a white paper around the topic, which I did. I released the proof-of-concept code a couple months ago on GitHub as MT.Net.
The white paper is being released today: Managing Content in the Transactional Application.
You can download it free from MT’s website. The first part discusses the problem, and the second part explains how to effect the solution and some of the challenges you’re going to run into. There’s a lot to think about, and it’s good advice regardless of the CMS platform you use to do it.
Hope you enjoy it.
(I also need to mention that Bryan Ruby over at CMS Report wrote a very flattering post about it this morning. It’s worth reading too, but perhaps that’s just because he says really nice things about me…)
By Deane Barker on March 13, 2014
Microsoft Surface: A Tale of Two Computers: A notoriously pro-Mac website reviews the Microsoft Surface and likes it.
[…] with Surface, Microsoft has created a kind of computer that is new, innovative, and exciting, while simultaneously not leaving the past behind. […] by forcing myself to revisit the Surface, I have come to admire that which I once dismissed, and to realize how alternatives to the Apple ecosystems can help move consumer computing forward in ways I had scarcely imagined.
(I’m cherry-picking a bit – there are plenty of negative quotes in there, but the spirit of the review is clearly positive.)
I saw a guy with a Surface in Stockholm once. It was amazing – an awesome tablet, then he hooked his keyboard, mouse, and monitor up to it, and it was a full-blown desktop PC. I was impressed.
By Deane Barker on February 19, 2014
We’re doing it again this year…
Now What 2014
We did this conference last year, and it was a huge hit. Reviews were fantastic – both attendees and speakers absolutely loved it.
This year will be even better, and that isn’t a marketing pitch. Here’s the speaker line-up:
I go to a lot of conferences, and this line-up is better than damn-near all of them. To have this group at my own conference is pretty amazing for me.
We added a workshop day where Jeff S. will be talking about analytics, and Corey will be talking about content maintenance.
The event is April 24 (workshops are the 23rd) in Sioux Falls, South Dakota.
We worked hard to keep it affordable too: the main event is just $250, which is an absolute steal. I defy you to find this level of content at that price, anywhere.Register Here