{"id":398,"date":"2013-07-31T06:25:03","date_gmt":"2013-07-31T06:25:03","guid":{"rendered":"http:\/\/www.seonthemon.com\/wp351\/?p=398"},"modified":"2013-08-09T16:04:00","modified_gmt":"2013-08-09T16:04:00","slug":"user-experience-for-the-techies","status":"publish","type":"post","link":"https:\/\/www.seonthemon.com\/wp351\/2013\/07\/31\/user-experience-for-the-techies\/","title":{"rendered":"User experience for the techies"},"content":{"rendered":"<p>What do I think of when considering &#8216;<em>user experience<\/em>&#8216; for the technical folk? \u00a0 What makes it easier to do their jobs? \u00a0What helps them do their jobs better?<\/p>\n<p>Techies include the following sorts of resources.<\/p>\n<ul>\n<li><span style=\"line-height: 13px;\">Programmers<\/span><\/li>\n<li>Testers<\/li>\n<li>Dev Ops<\/li>\n<li>Program Operators<\/li>\n<\/ul>\n<p>As always, common factors that I listed in the post, <a href=\"http:\/\/www.seonthemon.com\/wp351\/2013\/06\/25\/user-experience-in-an-enterprise-system\/\">User experience in an enterprise system<\/a>, apply to these resources as well.<\/p>\n<h2>Programmers can see everything<\/h2>\n<p>Interestingly, it appears that programmers occupy a special place in the enterprise. \u00a0 Everything, systems and data, that any corner of the enterprise sees and uses, must be accessible to some programmer or the other. \u00a0Who builds these systems? \u00a0Programmers. \u00a0Who do you call when anything goes wrong? \u00a0Programmers. \u00a0 Nothing can be hidden from the programmers.<\/p>\n<p>This means that the the user experience considerations that apply for everybody else in the enterprise, which I have written about in other posts, apply to programmers as well.<\/p>\n<p><em>One thought occurs to me. \u00a0 Doesn&#8217;t this kind of all-pervasive access raise privacy issues? \u00a0Not to mention security concerns? \u00a0I wonder how enterprises deal with this.<\/em><\/p>\n<p><span style=\"font-size: 13px;\">\u00a0<\/span><\/p>\n<h2>A Domain Specific Language (DSL)<\/h2>\n<p>Often, for some reason or the other, a programmer is asked to perform a business task. \u00a0The enterprise system typically supplies business users a graphical interface for this work. \u00a0Programmers can use that interface too. \u00a0However, programmers have technical skills that typical business users may not have. Further, programmers have responsibilities other than performing business tasks, which means they are looking to save as much time as possible.<\/p>\n<p>Hence, if it is possible to provide programmers an alternate interface, which is more powerful, and more performant, even if more technically complex, it would be a good thing.<\/p>\n<p>In some of my previous work, programmers did considerable customer support work. Often they would have to perform some activity that meant wading through pages and pages of UI, in order to make one small change, or press one button. \u00a0I heard them lamenting the lack of a more &#8216;expert&#8217; kind of interface. After all, they arguably had more technical expertise than the rank and file business users. \u00a0We could have used a scripting solution. A couple of lines of a well designed DSL (domain specific language), would have put them all in a good mood, not to mention saved a lot of time, and energy.<\/p>\n<p>Say that you have to change the type of roof, on the 3rd barn of the farm that is insured by farm policy, FU-237EKS. After the change, the policy must be assigned to an underwriter for review. \u00a0 In the UI, the change happens on the 8th screen of the farm policy. The assignment to the underwriter is a further 3 screens down. \u00a0 Rather than schelp through all that UI, some folks I knew would have liked to\u00a0execute something like this script.<\/p>\n<pre style=\"padding-left: 60px;\">FU-237EKS.barns[3].roof = shingle\r\nunderwriters['nate silver'].reviews += fp237eks<\/pre>\n<p>However, keep in mind that it ought to be possible to design the graphical user interface so that it provides the same kind of power, and efficiency. The recent, industry-wide emphasis on usability is all about this kind of improvement. \u00a0The point here is that alternatives to GUIs (graphical user interfaces) exist, which might more naturally fit programmers&#8217; sensibilities.<\/p>\n<p><em>I also wonder if there might be certain kinds of business functions that are hard to represent in a GUI. \u00a0Some complex, but one-off, workflow, which has to be created on the fly, for instance. \u00a0This is a question to explore.<\/em><\/p>\n<p>&nbsp;<\/p>\n<h2>Some items related to support<\/h2>\n<ul>\n<li>You must be able to change the logging level that is in effect without stopping the application.<\/li>\n<\/ul>\n<ul>\n<li>You must be able to add muscle to the system, without stopping anything. \u00a0Bring more servers on line, add more threads to a running server, and so on.<\/li>\n<\/ul>\n<p>&nbsp;<\/p>\n<h2>Software Configuration Management<\/h2>\n<p>Essentially, all of configuration management must be automated.<\/p>\n<p>Check out, and check in of code; build, test, assembly, and release of an application, must be completely scriptable. \u00a0You should be able to do all of this at a click of a single button, or the issue of a single command at the command line.<\/p>\n<p>In some of my previous work, even though the code base was all in\u00a0one source control system, we used to have to explicitly issue about\u00a060 check out commands. We never automated the check out. So to<br \/>\ncreate a new workspace, we would do a lot of manual work &#8211;\u00a060 clicks of the mouse, 60 commands at the command line.<\/p>\n<p>Releasing a new version of the application was a multi-step, manual\u00a0process, which would require some Dev Ops person to be up at ungodly\u00a0hours.<\/p>\n<p>Some releases, especially emergency patches, were horrendously complex.\u00a0Some poor schnook, sitting in India, used to have to painstakingly undo changes to\u00a0several parts of the code base, make the release, and then restore\u00a0all those changes.<\/p>\n<p>Needless to say, this was error-prone. Disasters, big and small,\u00a0begging to happen. \u00a0This should never be the case.<\/p>\n<p>Software configuration management (sometimes referred to as build management, release management), must never be a burden to the developer. \u00a0 Folks that specialize in this work (Dev Ops), must hide the complexity by automating it all away. \u00a0 If you are using tools that do not lend themselves to this kind of automation, well, you are using the tools that developers cannot love. \u00a0 This is infrastructure, which is meant to remove some of the drudgery from a developer&#8217;s working life. \u00a0 So let us have useful, and reliable, infrastructure.<\/p>\n<p>&nbsp;<\/p>\n<h2>Testing<\/h2>\n<p><!-- ^ Position is not set to relative \/ absolute here because of Mozilla --><\/p>\n<p>One of the most critical lessons of the Agile philosophy is the recognition that developers must also test. \u00a0 The Agile world asks, how does a developer know he is done with a task? \u00a0The Agile world answers, he proves it with tests. \u00a0When all of his tests run successfully, the developer is done with his work.<\/p>\n<p>Each developer must be able to test her work independently of other programmers. \u00a0 \u00a0This means that each developer must have separate sandboxes for code, and data.<\/p>\n<pre style=\"padding-left: 30px;\">Developers have their own sandboxes for code by virtue of using a \r\nsource control system.  However, in my previous work, I often \r\nencountered resistance to setting up independent sandboxes for \r\nthe data.  I never really understood this.  Why couldn't each \r\ndeveloper have their own copy of the system database for instance?\r\nIsn't this sort of thing quite inexpensive these days?<\/pre>\n<p>We must automate the generation, and load, of test data.<\/p>\n<pre style=\"padding-left: 30px;\">In one of my previous jobs, many tests required testers to create an\r\ninsurance policy.  These were manually entered, a laborious process,\r\nwhich took significant time.   \r\n\r\nAs you can imagine, testing was not as rigorous as it could have been,\r\nbecause it was just too hard to setup the data required for the test.<\/pre>\n<p>The system&#8217;s user interfaces must support automation. \u00a0 This is necessary not only for functional testing, but more importantly, for load testing. \u00a0 You have to be able to simulate many users banging on the UI. \u00a0 For this to be done with any kind of rigor, you have to be able to drive the UI with scripts. \u00a0Keep that in mind when you construct the UI.<\/p>\n<p>Tests must run continuously. \u00a0If you have &#8216;<em>continuos integration<\/em>&#8216; going, you have this in place. \u00a0 Continuous integration is a feature of software configuration management. \u00a0 Every time a change is checked into the source control system, you must automatically kick off a build of the whole system, which, by definition, includes tests. \u00a0 This allows you to find errors sooner rather than later. \u00a0 Continuous integration is possible only if all of your software configuration management is automated.<\/p>\n<p>Finally, a replica of the production environment must be available to the developers. \u00a0 Often, you run into errors that only seem to happen in production. \u00a0 Give developers an environment that is identical to production, where they can test, and debug problems, without messing with the production environment itself. \u00a0Without this, you are asking developers to be brilliant, which seems like a high risk strategy.<\/p>\n<p>&nbsp;<\/p>\n<h2>Techies other than developers<\/h2>\n<p>So how about testers, dev ops personnel, and program operators? \u00a0\u00a0These folks perform functions that have been covered above, and in earlier posts.<\/p>\n<p>The section on testing applies to folks that are exclusively black box testers. \u00a0 The section on configuration management applies to dev ops. \u00a0\u00a0Earlier posts on graceful processes applies to program operators.<\/p>\n<p>&nbsp;<\/p>\n","protected":false},"excerpt":{"rendered":"<p>What do I think of when considering &#8216;user experience&#8216; for the technical folk? \u00a0 What makes it easier to do their jobs? \u00a0What helps them do their jobs better? Techies include the following sorts of resources. Programmers Testers Dev Ops Program Operators As always, common factors that I listed in the post, User experience in [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[6],"tags":[8,40,18],"_links":{"self":[{"href":"https:\/\/www.seonthemon.com\/wp351\/wp-json\/wp\/v2\/posts\/398"}],"collection":[{"href":"https:\/\/www.seonthemon.com\/wp351\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.seonthemon.com\/wp351\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.seonthemon.com\/wp351\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.seonthemon.com\/wp351\/wp-json\/wp\/v2\/comments?post=398"}],"version-history":[{"count":10,"href":"https:\/\/www.seonthemon.com\/wp351\/wp-json\/wp\/v2\/posts\/398\/revisions"}],"predecessor-version":[{"id":416,"href":"https:\/\/www.seonthemon.com\/wp351\/wp-json\/wp\/v2\/posts\/398\/revisions\/416"}],"wp:attachment":[{"href":"https:\/\/www.seonthemon.com\/wp351\/wp-json\/wp\/v2\/media?parent=398"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.seonthemon.com\/wp351\/wp-json\/wp\/v2\/categories?post=398"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.seonthemon.com\/wp351\/wp-json\/wp\/v2\/tags?post=398"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}