So I tasked some of my gnomes and elves to do a little more work on the problem of the editor gutter. I gave them all the feedback received from this post just to see what they would come up with. So here's the result:
And optionally:
Hmm.... Actually I kinda like it. Who says you can't teach old dogs new tricks! Of course this is still subject to change if my gnomes or elves start getting cocky..
So, yesterday, Steve Trefethen, stopped by my office and had asked whether or not I'd gotten any internal feedback on what to do about the left gutter in the editor. You see, we have an internal blog and an internal wiki that we use to communicate newsworthy items and to float around technical specs among the various teams. Because we have teams spread across the globe, development is happening on Delphi almost 24-7, so it is usually much easier to dissiminate information via the internal blog than to spam everyone's email box. The Delphi Welcome Page for developer's builds automatically points to the RSS feed for the internal blog so most folks don't miss the blog information. Oh, things like meeting minutes, new feature status, build breakages, etc... are all published there, but I digress. You're here for a discussion on the left gutter in the editor.
As Steve and I were talking about the dearth of feedback we'd gotten internally, we spent a few moments and brainstormed (OK. I did get one bit of feedback, thanks Jesper!). I think we hit on an epiphany. We determined that the main cause of “fear and loathing” regarding the Delphi 2005 gutter was that it was actually packed with too much information. It was cluttered which lead to the general feeling of being disorganized. Myself being somewhat ADD, that clutter is easily overlooked, or at least minimalized. I knew something just didn't “click” with it, but couldn't quite put my finger on it. So as we brainstormed, Steve hit upon an what could be characterized as a “duh!”. What if we only painted every 10th line number and then placed little dots for the lines in between? The same information is conveyed, but every 10th was too far apart to quickly see what lines were in between. I didn't realize how much I relied on the line numbers in the gutter until we started changing things. So we tried to paint only every 5th line lumber... nope, still too cluttered. At first we painted '-' characters on the lines between the numbers... ick.. that made it look like a ruler. So we went with the dots. That was better, but every 5th line was still too many line numbers cluttering things up. So, again, Steve, suggested we paint a '-' on the 5th line between the numbers and dots on all the rest. Wow! That is actually starting to look good. Here's what we've go so far:
That's far less cluttered, don't you think? The “-” character clearly deliniates the 5th line. With just a little more effort, we think it will quickly become second nature to be able to glance at that and see what line number a particular line is.
Now that the line numbers are not so prominent and “out there,” let's tackle the “overlapping icons” issue... The problem we're trying to solve here is that there is a lot of information we want to convey visually from the left gutter. Things like breakpoints, bookmarks, breakpointable lines, current execution point, etc.. All of this information takes precious real estate from the really important information, the source code. So we compromised and placed the icons over the line numbers and also tried to change the intensity of the line number to be less prominent. The problem with playing with luminance and saturation is that many times those value tend to wrap around and actually create a much brigher color. The reason for “dimming” the line number was an attempt at reducing the clutter I talked about above. So we disabled that “feature.” Now that the gutter is far less cluttered, lets look at what it would look like now with the infamous “blue balls.”
Hm.. That's getting there. The breakpointable line icon is clearly visible and easily overshadows the line numbers making them very visible. They also don't steal any more real estate. So what about bookmarks and the current execution point?
Notice that the breakpoint glyph doesn't overlap the bookmark glyph. However the excution point arrow does overlap. This is on purpose. Those are related items. The breakpoint glyph and the execution point arrow glyph are all about debugging. Notice that the blue ball is also covered up. Why continue showing that when it is clear that the breakpoint has been set there? You can still see the breakpoint under the arrow, so there is no need to take up more real estate. Notice that the line number has taken a complete back seat to all of this. They're not as an important piece of information as the bookmark, breakpoint and execution point glyphs are. Also since there are no line numbers painted on the adjacent lines, there is far less surrounding clutter to detract from where the real information lies.
Finally, lets look at what happens when the gutter is too narrow to display those two glyphs side-by-side without also spilling into the code folding information. At this point, the glyphs will begin to overlap, but only to a certain point so that all the glyphs will be at least partially visible. But we've rearranged the priority of them so that the bookmark is always on the bottom, then the breakpoint/breakpointable glyphs, finally the execution point is alway on the top.
As most source files tend to be more than the mere 30 lines we see here, the gutter will generally be wider and thus there'll be far less overlap between the glyphs. Hopefully we'll see some derivative of the above changes in the next Delphi release. Since this is only a start, I'm sure we'll be refining this even further, and since I have no delusions of pleasing everyone, I think we're on the right track.
I thought I'd take a moment to dispell any myth regarding whether or not we take the current (or past) Delphi survey seriously and they really don't end up in some black hole. In between Mods E and F here at the Scotts Valley, CA campus, there's an entire wall that is one huge dry erase board (whiteboard). Just yesterday, the latest preliminary survey results were printed and taped up on that board for all to see (internal to Borland that is). It is quite interesting to read over all the results. Now one item of note is that while we do take these surveys very seriously, they are just a part of the overall picture. We also take into account a lot of information from our field sales teams, the Product Line Sales Managers for the various regions, and customer site visits, etc... The following photos (taken with the now infamous phone cam...;-) are just the results from the Delphi 2005 users only, so there's a lot more data to mine. This was also only after the first day the survey was posted. No, I'm not going to provide higher resolution photos because we generally don't publish the results of these surveys. Mainly because of what I said above; they are only a part of the overall picture (no pun intended ;-). As we mix in data from all the other sources, things could vary substantially from the raw survey results. Besides, raw or cooked, internal marketing data is a critical business datapoint and should be held very close... why hand free marketing research to your competitors?
If you look closely at the picture on the left, you can see the written text “1st Day results...” Also, nevermind the tic-tac-toe game to the left ;-)...
Mark Russinovich, of SysInternals fame, posted this blog entry about the new Windows XP 64bit Edition. Why do I mention it? Well, for one thing, Mark mentions using Delphi 2005. Unfortunately, his reference to Delphi isn't too flattering.
“The Borland Delphi 2005 debugger has a more serious issue: when you launch a process under the debugger it believes that the process exits immediately when the process actually starts properly. A workaround is to attach the debugger to the process after its launched.”
This blog post was brought to our attention, so I posted a comment asking for some clarification and some steps to reproduce this problem. This was in addition to the internal flurry of emails and immediate investigation into the problem on one of the 64bit systems in the QA lab. However, based on the above description, we tried to reproduce the problem and found that we could not. Obviously, we're not trying to debug a 64bit application (Delphi isn't quite there, yet ;-). Mark responded quickly with more information regarding what he was actually trying to do. It turns out that he was trying to debug an MMC (Microsoft Management Console) snap-in written in Delphi. After another internal flurry of emails and work in the QA lab by a member of the QA team, we looked and found out that mmc.exe is in fact a 64bit application. OK... now the SysInternals guys are some smart cookies, and I could not for an instant think that Mark would make such a silly and obvious error. It turns out that there are two versions of mmc.exe, a 64bit version and a 32bit version.
So after I post a rather sheepish response (in which I inquire as to the “bitness” of mmc.exe... I was a little embarrased to even mention it) to Mark's explination of what he was doing, Mark responds with what is actually going on. Yes, of course, he's launching the 32bit version of mmc.exe from the Delphi 2005 IDE. But what happens is that the 32bit MMC then immediately turns around and launches the 64bit MMC and then exits. Ok this makes sense. But, he mentions that he's able to attach to the process after it is launched. This is easily explained as well as Mark states in his response comment:
“I've investigated further and its a Windows problem, not Delphi's: when you launch the 32-bit mmc.exe it launches the 64-bit mmc.exe and exits. If you are loading a 32-bit snapin the 64-bit mmc.exe launches the 32-bit mmc.exe again and exits.”
So the mystery is solved. And Delphi 2005 runs and debugs 32bit applications on the new Windows XP 64bit Edition. So thanks, Mark, for bringing this to our attention and being so proactive in figuring out this odd behaviour. And finally, it is really awesome to know that the folks at SysInternals use Delphi!
Follow up: It looks like Mark figured out the issue and how to launch the 32bit MMC. He explained in his comment:
“ Ah, I figured it out: you can launch the 32-bit mmc.exe directly if you specify its path (windowssyswow64mmc.exe) and include the /64 command-line option.”
When we look to hire a new junior/entry level engineer, there are several key qualities I look for in the candidate. The first and foremost quality I want to see, obviously, is talent. Do they really know the stuff they said that they did on their resume(CV)? Another quality that is one of the hardest to see in a short interview, although I have seen it come out in the really exceptional ones, is enthusiasm and excitement. Don't be afraid of being wrong. How else do you learn? A corollary to this one is teachability. How well do you respect both your peers and the senior developers?
Clearly, the most successful and talented engineers tend to meet those above qualities. I'd rather hire an engineer that was less experienced but was a fireball of energy and enthusiasm. Also they are ones that would be willing to charge ahead and take risks, even if it is the totally wrong direction. They are kinda like a pinball. The times when the game is the most exciting is when the ball is bouncing around in all different directions. And you can think of the senior engineers as the paddles. They are constantly redirecting and sending the ball back into play, which is how you score the most points.
Yes, that metaphor will break down at some point because eventually that pinball will need to become a paddle. My point is that an engineer may have memorized Donald Knuth's books but is so afraid of making a mistake or “not measuring up” in the eyes of their peers or the senior staff, that they are paralysed by this fear. Yes, they will complete a task... eventually... and it will be correct and relatively bug free. The problem is that you don't know when it will be complete. And sometimes, it may not get done at all. Someone who is willing to make mistakes and can take direction and critiques, will usually outperform someone who tends to be paralyzed by some fear.
Of course, this person can become a liability, but that is usually when they fail the final item in my initial list; teachability. So taken altogether, a junior engineer with the above qualities has the most chances for success. Coming onto the team with agendas, and preconceived ideas on how things should work, and refusing to accept that the more experienced team members may have already thought about all the various angles, is a sure recipe for disappointment and discouragement. In my direct experience of being on the Delphi team since its inception, I've seen both types come and go from the team. I'd have to say that for all the junior engineers that have come and gone on the Delphi team the ones that met the above conditions have contributed to the team far above some of the more reticent members have done. I've enjoyed watching some of these junior team members move up into the senior ranks. They are given larger, more critical tasks. They also don't require as much guidance and direction... but what is an interesting trait they tend to develop is they now actively seek out feedback and criticism from their peers and the top-staff members. They usually have spent a good amount of time thinking about the problem critically, and mulled over several solution scenarios. By the time they begin seeking feedback, all the “stupid” questions are out of the way and the real “meat” of the problem can be discussed.
Now before you start reading between the lines and think that I'm trolling around for new hires, this is just a few thoughts I've had recently and thought I'd get them out before they evaporated. Which probably explains why some of my metaphors are a little odd at times... then again when you consider the source... ;-)
So while I'm waiting for the latest new bits of Delphi goodness to be assembled into some machine readable goop... I figured I'd take a few moments to spew a few thoughts...
You know those little “X”s on the editor tabs in Delphi 2005? The ones that you either absolutely revile as the spawn of the devil, or on the opposite side, they're the Messiah's second coming. Quite frankly, I'm someplace in the middle... well maybe more toward the Messiah side... When we were considering putting them into Delphi (ie. the Galileo IDE), we looked at how these little images of controversy were handled in other environments. The first such environment, which was also the most logical, that we looked at was JBuilder. So we fired up JBuilder to do some research (such as it was). After playing around with them for a while, I found some usability issues with them, but overall Corbin and I really like the idea. (an aside: the Eclipse IDE has a similar feature as well) Here's a few that I found...
The first item is probably the #1 complaint among the “spawn of the devil” crowd. I, too, sometimes have found myself accidently clicking that little “X” when I don't fully pay attention to what I'm doing. I mean, I'm deep in the middle of a bug fix or some sort of feature work and I want to click over to some other tab, and bam! I just closed the tab. So now I just Alt-F,R,5... That's File|Reopen|5. . I've just gotten used to quickly doing that little dance. OK.. so that's the first problem.
The next one is... well... really hard to quantify. If you hate the “X”, then #2 is probably one of your supporting arguments for removing them. That's fine, but I also think it is a data point that also can stand on its own. Screen real-estate is a finite resource and needs to be carefully parceled out. Now that doesn't mean that we create butt-ugly UIs under the pretense of the almighty screen real-estate. It means that there needs to be a balance. I often hear folks, especially among the software engineering illuminati, “We don't need all that eye-candy!“ Riiiight... If that were the case then we'd all be driving Gremlins, Pacers, or Pintos. That's why I have a Monet print and an actual oil reproduction of a Monet painted by my mother hanging in my office (both from the Water Lilies series, for which Monet is very famous. And yes, Monet is one of my favorite classical artists). Right next to the cool 4ft (120cm) wide poster of an F-15E in flight... All of it is “eye-candy.“ Of course these posters all have their own stories themselves, which I'll save for another blog entry.
The last item is somewhat subtle. One of my first thoughts when I saw the “X” on the tabs, was “That's cool! I can now quickly close a lot of files without a lot of clicking or mouse movement.” Well.. not quite. So you would close the tab, and the tab to the left would slide over, but that tab is a different width that the one just closed, so now the mouse cursor isn't directly under the “X” and you have to move it to the left or the right and click again. Grrr... Of course, if you have a habit of double-clicking, you'd probably appreciate that the “X” didn't appear under the mouse cursor.... sometimes.
So with all these negatives, why the blazes did you put that in the product? First of all, it is just so dang useful and convenient. Also, we solved the #3 problem by having the tab to the right slide over, which would always put the “X” right back under the mouse cursor. It's also kinda like chocolate.. you know that too much of it isn't good for you, but in moderation it's pretty tasty.
So, now that we've shipped a couple of products with the “X” and have received some feedback from all the various factions out there. You know, the “spawn of the devil” folks and the “Messiah's second coming” folks. So we're considering a bit of a change. What if the “X” was at a fixed location? Say it was all the way over to the right side of the tabs?
That would solve the all the complaints I listed above. However it would introduce another problem. Since there is now only one “X”, you can only close the active tab. Which was one nice thing about the “X” on the tab; you could close an inactive tab by clicking on the “X” directly. I suppose we're at a point where a descision needs to be made. Right now, we're internally using this change for the next release of Delphi to see how folks like it. So far the response has been positive... well OK, not all positive since there are those that “want their 'X' back!” Now before you suggest it, no, I'm not going to make this optional. So we have to weigh the advantages and the disadvatages. So far, I'm inclined to think this is a reasonable compromise between both camps. Be warned, however, please keep your comments to the point and well thought out. Any comment I think is disrespectful and rude, I'll delete. Think critically about the problem, and consider each side regardless of your personal opinion. Yes, ultimately, the original decision was based on our (the developers and the overall team's) personal preference, and it still is. Yet, feedback is still key in how we form our preferences and opinions. Being, ourselves, developers we like to think of ourselves as advocates for the customers. Like all groups, there are the radical fringes, but you have to take the bad with the good.. and luckily, for the Delphi community, it is mostly good. It makes our job more enjoyable and satisfying.
With that, have fun... ;-).. And, hey, if this works out, I might try and address the “my glyphs are overlapping in the editor gutter!” (OK, Nick?) issues... Talk about a field full of landmines...
Brian Long, Delphi Consultant Extranordinaire, has some cool web pages describing all the various “Easter eggs“ that have been in Borland products over the years. I'm somewhat partial to this one in particular...http://www.blong.com/Undocumented/Delphi5.htm. In other words, the text file and project manager trick.
For the record, though, I did not put this one in the product. There was a period of about a year and a half where I played R&D manager in addition to having actual product deliverables for which I was responsible. It was done by two of my direct reports, specifically, Chris “debuggers 'r' us” Hesik and Dave “I don't have a blog” Wilhelm.
Someone in the Delphi non-tech newsgroup had posted this link to the NASA Goddard Space Flight Center Rapid Application Development Lab that explains their rationale for using Delphi in the creation of the Data Trending & Analysis System (DTAS)... uh.. whatever that is ;-). But hey, its written in Delphi! If you browse to the “Introduction” page (or follow this specific link), there is an excellent paragraph describing their reasons for selecting Delphi as the tool of choice. The best quote is “ (i.e., it placed no measurable limits on what we could develop).” That about sums it up...
