From time to time people will ask questions about how to make TinyMCE do something that it's not really designed to do. This is mostly to output non-standard HTML and is usually due to the "client requirements". The most common one is the use of <BR> tags instead of <P> tags.
I'm not going to join into the argument of using <P> tags as a good friend and colleague posted a great round up of the importance of P tags already. What I'm interested in, is the way people respond both in terms of the initial question, and the followup responses.
From what I've seen, the response to these sorts of questions can occasionally be quite harsh and usually question "why" the person is even contemplating doing this. Now while I don't always agree with the tone of the responses, I can empathises, especially if they've had to answer the 100th question that has been addressed elsewhere, including the documentation.
The disturbing trend I've recently seen however is in the reaction of some people to this "criticism" or questioning. It appears people believe we should ignore the reason why someone is doing it, and simply answer the question. I tend to disagree.
As a developer I believe it's my duty to educate, as well as assist people. This includes both other developers and clients.
I believe that there are a lot of people out there who don't know any different with respect to the choices of output. By questioning why they are doing this and ideally providing the more acceptable alternative, the respondent is potentially educating them. Now it may be that the developer knows this already and is unable to educate their current client, but for others, they may now know an alternative. They still mightn't be able to change their clients mind this time around, but they will be better armed for future engagements.
]]>The other day I watched a presentation by Jesse Desjardins called "You Suck at Powerpoint – 5 Shocking Design Mistakes You Need to Avoid".
Along with many useful design mistakes, he made an interesting observation that
Most experts say: An outstanding 1-hour presentation takes 30 hours or more of prep time.
— Slide 39
Shortly after I was doing a demo with our European sales rep. It was the first time we had demo'd together and during the post demo debrief our VP Sales, Tom Smith, observed that role playing the demo together could have smoothed out a few rough edges in our interaction. This was especially important given everyone on the call was remote from each other.
In the book "Great Demo", by Peter Cohan, he discusses the cost of a failed demo. As this can be quite significant, including loss of the sale, it pays to take the time to prepare properly.
Now this got me thinking – just how much time should we invest in preparing for a demo?
Obviously there’s the time spent setting up your demo environment, ensuring you have data/examples relevant to the customer and identifying the key features of your product that the prospect is really interested in. However there is also the time spent with the sale rep going over the "game plan" for this particular customer.
Now I normally work with our APAC sales rep and he and I have built a good report. Interestingly this was built initially face-to-face when he was on a sales trip to Australia. In the case of the demo with the European sales rep, while we had prep'd with the customer the technology to do the remote demo, we hadn't spent any time together going over how we would interact during the demo.
So, the time to prepare for a great demo can be quite significant and involve setting up the demo, and working through the approach with the sales rep. Of course, if you are doing a demo for the first time with a sales rep, then you need to invest even more time working out your interaction and how each of you prefers to work with the prospect during the demo.
At the end of the day, all of this effort is there to maximise your success in the demo and ensure you move even closer to closing the deal. So spending less time preparing could be lead to a failed demo.
]]>
His story reminded me of the differences in service I experienced earlier this year during the migration of our two phone lines when we moved offices.
We have one line for voice, and the other for internet, each provided by one of the two major telecommunication carriers in Australia. As such, migration was to be simply installation of a suitable line at our new office and termination of the existing line. Of course these things never go smoothly but it was the approach to customer service that surprised me.
When I wanted an update, or had an issue with the line Telstra was responsible for, I had to ring their support line, battle through the "voice recognition" system, explain to the person what we were doing, why it wasn't right, etc, then wait for a response. Everytime I did this I had a new person so the process was repeated.
Optus however allocated me an account migration manager and I was given their direct number. At any time I could call her up and she'd be able to give me an update, or get back to me with one if she didn't have details to hand.
Compared to the experience with Telstra, having one person to talk to with Optus greatly improved the process for me. This simple difference resulted in the customer service experience with Optus being a "delight" and contributed to a less stressful migration of their line than Telstra.
]]>
One of the offices is very evidently a call-center. It’s clad in shades of grey and blue with small cubicles. It seems to suck the energy out of you just looking at it.
The other (pictured) seems to draw you in. In fact, upon entering, I had not idea what they did1, but you felt that it would be an interesting place to work.
It may seem obvious, but it’s important to consider the impact your office environment has on potential employee’s as well as the current ones.
When recruiting, if a candidate walks in the door thinking, “wow, I want to work here”, or compares favorably your office/team with their current office and team part of the hiring process just got simpler.
For your own staff, having a place that they want to work in, along with an outstanding team to work with brings it’s own rewards. Higher productivity, less down-time due to illness and greater retention to name just a few. These rewards have value not easily measured but a lot higher than what it can cost to make a great environment.
1 – My wife’s first guess from the photo was travel, but it turns out they are a tattoo artist.↩
]]>The celebrations kicked off with a party on Thursday followed by a weekend away at the Hyatt Coolum for employee’s and their partners.
While the weekend away did provide an opportunity to talk shop, it was the personal conversations that I feel pay the biggest dividend.
At Ephox we make great use of digital communication tools like Skype, e-mail and instant messenger to keep in touch. There is something however about talking to someone face-to-face, that allows you to connect on a different level. It’s the conversations over breakfast, the corporate dinner, pre-dinner drinks and while playing tourist that allow you to connect with our colleagues in a way that electronic means just can’t achieve.
In this relaxed environment, you find yourself talking about previous experiences and roles as well as sharing a joke or two. Add to that the ability to meet and talk with your colleagues partner and you begin to build a more complete picture of the person.
So what does this mean for us now we are all back home? The personal connections made enhance our business relationships and communication. The insight gained allows us to filter digital communications through their respective personalities, enriching the experience. In addition, the “back-story” of each person will allow us to better utilise their previous experiences/skills.
]]>We recently had a practical session, as part of our continuous learning practice, on TDD. After the first few tests, Doug got into some serious refactoring to make the code clean. As Doug progressed, I found myself becoming increasingly frustrated with the numerous methods, many of which had 1 or 2 lines of code, that he created.
I started trying to understand what Doug was trying to achieve and why I was finding it frustrating. As we discussed the aim of Clean Code and how Doug would “read” the code, it dawned on me that the difference was in detail. Doug would read the initial method, accept the definition inherit in the method names called, and drill down to those lower methods only when required. I on the other hand found I needed to drill down through the many layers of methods to better understand the initial method.
It was this difference to how we went about understanding a program that was making his extreme Clean Code approach work for Doug and not for me.
In previous lives both Doug and I have done a Myers-Briggs assessment and interestingly he is an N while I’m an S. In the Myers Briggs assessment, the Intuitive (N) preference person works from the “Big Picture” drilling down to detail when required, while the Sensing (S) personality is the opposite.
When I did my Myers-Briggs assessment we discussed the need, when presenting to a room of people, to take into account the various understanding approaches inherit in the S and N preferences. Similarly, when you are teaching, my wife informs me, you need to take into account the learning styles people have. For example Auditory versus Kinesthetic.
So, when you are “cleaning” code, take into consideration that the people reading it in the future, may not approach it the same way you do. You need to strike a balance between cleaning up the code into more manageable methods, but not to the point where you have many layers of increasingly smaller methods. Not everyone will save time reading this code, but rather it will take them significantly longer.
]]>At Ephox, we have quite a lot of UI design required and as such we’ve tried a few different things from quick Java mock-ups to Photoshopped images. To me however the best solution is the paper sketch. Why, well other than it being pretty cheap to develop and modify, anyone can do it, including the “client”. Finally, there’s also no chance you will be tempted to use the “prototype/mockup” as the basis for the final version.
]]>