When I spoke at the New England SQL user group meeting yesterday, an interesting question came up. An audience member spoke about Agile development, and he mentioned that, because of the nature of Agile, document projects were doomed to fail.
At this point, I should mention a few things.
- I currently work in an environment that uses Agile development methodology.
- Just because I work in said environment doesn’t mean I know anything about Agile.
- Even as my workgroup’s technical writer, I am considered a highly valued member of the workgroup.
- Somehow, we make it work.
In regards to #4 above, the gentleman had a simple question: “How?”
This question came up during a point in my presentation in which I argued that document projects should be treated like software — in that, in an ideal environment (stop snickering!), a formal document should be subject to planning, development, and testing. This is a point that I’ve alluded to before.
The person asking the question went as far as to say, “if you can make the case as to how Agile can make technical writing projects work, then you should make a presentation out of it — and I’ll even help you sell it to Agile.” He even gave me his business card. Indeed, one of my big reasons for writing this article is as a reminder to myself to revisit this subject — after I’ve had a chance to do some homework about Agile development. It’s something I’ve been meaning to do; I even went as far as to begin a draft article about Agile development.
So, to the gentleman who brought up this (great) question, you were heard. And I will make sure that I come back to this at some point — once I’ve had a chance to do my homework on Agile.
During a recent work meeting, we were discussing an online Wiki-like internal document that I’d written. There was mention of a line that needed to be included. I mentioned that I’d need to figure out how to word it, and where it should go — pretty typical work when editing any technical document.
For some reason, during that conversation, I started thinking about how locating that — and other pieces within the document — affected its readability. That thought made me think about interfaces — how certain UI/UX pieces on an application can influence how an end user views and uses it.
That’s when it occurred to me: there is a direct correlation between technical writing and UI design.
It should be an obvious idea, but for me, it was a revelation. There isn’t a lot of difference between how a document is laid out and how a user interface is arranged. Many design principles between them are the same. The user’s eye path follows the design. How he or she reads the document or uses the application is affected by how the document is laid out or how the UI is designed.
I’ve written before about how design is important. I’ve also written about documentation issues (time and again). Like everything else, technical writing and UI design is a skill. A good technical document and a good user interface both require planning — as it turns out, the same kind of planning — to execute properly.
Things are getting busy. My SQL Saturday presentation efforts are paying off. It seems like I have a lot of stuff coming up! So for those of you who are having trouble keeping my schedule straight (like I am), here’s what I have so far.
I’ve also applied to speak at the following events. I don’t yet know whether or not I’ll be speaking at any of these, but we’ll see what happens.
There are some other events for which presentation applications are not yet live, but once they are, I intend to submit to them. They include:
- October 5: SQL Saturday Pittsburgh
- November 5-8: I intend to apply to speak at PASS Summit, Seattle! PASS Summit has been described as “the Super Bowl of SQL Saturdays,” so getting picked to speak here would be a big deal. We’ll see what happens!
So that’s how my schedule is shaping up so far! Of course, as the year progresses, this schedule is subject to change.
I’ll see you somewhere on the road!
Greetings, data enthusiasts!
This is a reminder that our February CASSUG meeting will take place on Monday, February 11, 5:30 pm, in the Datto (formerly Autotask) cafeteria!
Our guest speaker is Rie Irish! Her talk is entitled: “Well, actually… How to not be THAT guy in IT”
For more information, and to RSVP, go to our Meetup link at http://meetu.ps/e/FWkQ4/7fcp0/f
Hope to see you there!
I will be giving my first virtual presentation on March 8!
At 2:00 pm (US Eastern time), I will do my presentation: “Networking 101: Building professional relationships!”
That means YOU can attend! You don’t have to go to a SQL Saturday or a user group meeting! Go to the above link and register!
Hope to “see” you there!
I just got the official word! I will be speaking at SQL Saturday #813 (BI edition), Boston (actually, Burlington), MA on March 30! This is my first scheduled SQL Saturday presentation for 2019!
I will do my presentation on talking tech-speak to non-technical people!
This will make three times (all in the same building, no less!) that I’ve spoken here since this past September. The first was for SQL Saturday #797, and the second will be in two weeks for the New England SQL Server User Group.
Hope to see people there — either in a couple of weeks, or at the end of March!