What’s the next big thing? AJAX? Ruby on Rails? PC Virtualization? Open-Source Software? Data Security? Open Office File Formats? Windows Vista? Windows Live? Apple’s iWhatever? Yeah, all those things will get lots of hype, but the next big thing is something we’ve had access to all along:
Simplicity
Are my thoughts revolutionary? Nah, I’ve been reading about it at places like Information Week and the other usual suspects. Even Bill Gates at Microsoft gets it, through Ozzie at least (though execution will be the key.) But unlike all that gets hyped, simplicity as a concept that is for real.
Let’s look at two of the best known examples:
- Simple Mail Transfer Protocol.
- Really Simple Syndication.
Over the years, the world’s Internet email infrastructure evolved from that simple little mail transfer protocol (spam and all!) And RSS exploded as a method to syndicate blog posts in a very short order instead of one of the many complex content syndication concepts most of us never even heard of.
To most people the Internet came out of nowhere ten (10) years ago yet it evolved for at least twenty (20) years prior. The Internet’s foundation protocol TCP/IP isn’t exactly simple, but once the simple protocols HTTP and HTML were layered on top, Internet use exploded because implementing websites was simple (by comparison.)
But it’s not just simple technologies, its also simple to install and simple to use applications: ASCII text editors (i.e. Notepad), web browsers, email clients (w/apps like Outlook Express), instant messenger clients, wikis, blogging apps, online forum apps, and QuickBooks (simple is relative; accounting is required yet QuickBooks doesn’t really require accounting expertise.)
And to many people this simplicity makes sense. Scott Cook (founder of Intuit) got it. The founders of the original Instant Messenger (ICQ) got it. Pierre Omidyar (founder of eBay) got it. Google gets it. The original author of PHP Ramus Lerdorf gets it. And a lesser known group also gets it; the developers of Basecamp (although 37 Signals could also be the poster child for when a group elevates a concept to an ideology, and like all ideologists, becomes blind and misinterprets the concept. But I digress…)
Okay this is all obvious, and well, it’s simple. So what’s the big deal? People recognize that simple is important but without a simple roadmap, most don’t know how (pun intended.) I don’t know that I can provide that roadmap, but at least I can get you started.
First, just for grins, let’s look at some counter examples:
- MS-Access – Have you ever tried to develop an app is MS-Access? Yeah right.Access it pretty easy in where it allows you as a user to point and click, but once you hit its brick wall of end user functionality, you’ve got to be an Access guru to do anything more with it.
- VB.NET – Thank god for the My namespace in VB 2005, albeit five years late, but VB.NET is still too damn difficult to use productively without weeks of learning.Don’t get me wrong, I love the power of VB.NET language, but it has very little transitionality.
- ASP.NET – I know its blasphemy, but let’s be real: VIEWSTATE, __doPostBack(), Server Controls, @Register, @Import, WebForms, DataGrid, etc. etc. There’s so much complexity there, where does one start? It’s no wonder so many people still use ASP & VBScript.
- Exchange Server – Oh my god! How complex a beast can you get? Most POP3/SMTP servers use files and directories; Exchange using some bastardization of an Access/Jet database that corrupts whenever the power fluctuates. And have you ever tried implementing server events?
- SharePoint – I can’t even figure out SharePoint as a user, let alone as a developer. What was Microsoft thinking?
- Active Directory – Need I say more?!?
I’ve bashed on Microsoft thus far, but let me not give them all the credit:
- XML, though itself simple, has been complicated with namespaces which I’ve studying for literally years I but still can’t figure out how to use.
- SOAP – Okay, Microsoft was heavily involved here. But why did they have to make web services so hard?I mean, what was wrong with HTTP POST?
- J2EE – There’s a reason J2EE developers get paid the really big bucks.
- Oracle – Have you ever tried to tune an Oracle database application?
- Content Management Systems – Is there anything out that can pass for simple? I’ve been using DotNetNuke on one of my sites for a while and I can tell you, it isn’t.
This brings me to my key point. Aside from being intuitively obvious, what’s so great about simple?
The Benefits of "simple" are, quite simply:
- For the User: Productivity
- For the Platform Provider: Rapid and Widespread Adoption
But you say that all of my counter examples have widespread adoption?
Do not underestimate the institutional will of large organizations to implement tremendously complex technology, because they can.
On the other hand, departmental users, users in small businesses, college students, home users and more can’t deal with complex technology. If it’s too difficult, they don’t or can’t use it. And there are many, many more of them than there are large organizations. What’s more, large organizations are effectively made up of these small groups and individuals. Simple technologies benefit all.
Microsoft, with its Windows monopoly has been able to get away with complexity and consequent low user productivity and low platform adoption with many of its products for a long time. But with the new challenges from Google, SalesForce, et. al. they better get pragmatic religion, and they better get it fast.
And that roadmap to which I referred? To quote Albert Einstein:
As simple as possible, but not simpler
:-)
In a earlier blog I spoke the need for transitionality in development tools. One area of greatest need is in Microsoft Office; Outlook, Word, Excel, et. al.
Why Office? Recent versions of Office have provided almost full programmability, a nice object model, a macro recorder, and so on which helps power users automate processes and allows programmers to create applications using components of Office. However there are a woefully small number of people who actually program Office apps given the number of Office users. I believe that although Microsoft gave us great power by making Office programmable, they did not make programming Office accessible. They did not provide transitionality.
Case in point: I was just using Word 2003 and I needed to do a search & replace but search and replace didn’t work for what I needed so I decided to use a macro.
By the way, I was creating a mail merge document and I could not get Word to replace my placeholder text (i.e. ““) with a merge field (i.e. “«CompanyName»”) because a merge field is special. I needed to use a placeholder text because Word 2003 won’t let me add or change fields in my Access database unless I close the Word doc and firing up Access. What a PITA! And definitely a step backward from prior versions.
I recorded the following macro that did a “find” on my placeholder and then inserted the appropriate merge field:
Sub Macro1()
Selection.Find.ClearFormatting
With Selection.Find
.Text = “”
.Forward = True
.Wrap = wdFindAsk
.Format = False
.MatchCase = False
.MatchWholeWord = False
.MatchWildcards = False
.MatchSoundsLike = False
.MatchAllWordForms = False
End With
Selection.Find.Execute
ActiveDocument.Fields.Add _
Range:=Selection.Range, _
Type:=wdFieldMergeField, _
Text:=”"”CompanyName”"”
End Sub
I tied this macro to Alt-Z and if worked fine. Except I wanted to have it pop-up and ask me for the name of the merge field. And if it didn’t find the placeholder, I did not want it to insert the merge field.
Now I view myself as a pretty good programmer; not the best, but decent. I taught object-oriented programming before it was fashionable (over 10 years ago.) I studied programming as a sideline in college, I’ve programmed in over 10 languages, I wrote a 1000 page book on a programming language product called Clipper, and taught corporate and government developers how to program for seven years, and written a good portion of the VBxtras and Xtras.Net websites over the years, include both the front-end ASP and back-end SQL. So I’m not the typical occupational/hobbyist developer, but my role and position only allow me to program occassionally.
It took me 30 minutes reading help files to learn how to add my desired features to my macro. It shouldn’t have taken me that long. What about the power Word user who doesn’t have the same experience I have? They would have given up (I certainly should have because I didn’t get 1/2 hour of value out of my macro.) Of course a programmer who has worked with the Word object model might say “Duh?!? That is soooo easy! How could you not figure that out in 2 seconds?” But that is the point.
My point is the people most likely to make best use of programming Office are the ones for whom programming Office is generally over their heads: power users. And programmers generally only use Office as a component within other applications; they don’t know what really needs to be automated when using Office; power end users do. If power users were empowered to easily program Office, thousands of freeware, shareware, and commerical add-ons would be developed some of which would form the foundation of new 3rd party add-ons companies. For the most part this hasn’t happened, and all Office users miss the opportunity to use add-ons that were never developed. Microsoft went to tremendous expense to make Office programmable, and are getting a pitiful return on that investment.
What to do? Though I don’t have the answer, I do have some suggestions:
- When recording macros, include commented-out code that would show how to do something a user might obviously want to do if they edit the macro (i.e. after a “Find”, put a comment in showing how to test to see if the item was found.)
- Implement toolbar options using short macros and make it brain-dead easy for people to view the source code such by providing a “View Source” option on right click.
- If using short macros to implement most toolbar options is not viable, do customer research to find out the most common small tasks for which people could use macros and add special macro toolbars for those, with brain-dead easy access to view source.
- Do research to find out what the most common needs are when coding and create drill-down wizards that insert snippets of code for those common needs (i.e. “Need to ask user for some information and store for use in macro?” for which the wizard would insert compelete code for using InputBox)
- Do research to find out what higher level needs are and let power users run wizards to write complete macros for those higher level needs.
My hope is someone at Microsoft involved in programmability for Office will see these things and realize that if they could make programming Office more accessible, a lot more people would start programming Office. In future blog posts I’ll give new example of when I find difficulty doing something quick and dirty with Office macros as I run into the inspiration for them (I know I will.)
By the way, here is the updated version:
Sub Macro1()
Dim strFieldName As String
strFieldName = InputBox(”Field Name:”)
Do
Selection.Find.ClearFormatting
With Selection.Find
.Text = “<” & strFieldName & “>”
.Forward = True
.Wrap = wdFindAsk
.Format = False
.MatchCase = False
.MatchWholeWord = False
.MatchWildcards = False
.MatchSoundsLike = False
.MatchAllWordForms = False
End With
Selection.Find.Execute
If Selection.Find.Found Then
ActiveDocument.Fields.Add _
Range:=Selection.Range, _
Type:=wdFieldMergeField, _
Text:=”"”" & strFieldName & “”"”
End If
Loop While Selection.Find.Found
End Sub
