Topp Engineering

It has taken a long time since I’ve started on trac work to get to the point where I know what my goals are for trac at TOPP  and am able to articulate them.  I’ve decided to blog this at TOPP-engineering….ifI put it in the wrong forum and this offends you, feel free to yell at me in private.

Firstly, to recap the question that seems to be asked every couple of weeks, why trac?  I’m not going to go into too much detail, but trac is nice because it is

 * mature

 * python

 * malleable

 * fast to develop in

 * open source

 * a strong community

Trac out of the box is not an amazing issue tracker.  But with a little love, trac can be not only an amazing issue tracker but a huge part of the technical solution to software development communication (and beyond!).

Moving beyond advertisement, as I really have no incentive to push for trac, but to figure out what sort of place trac development could have in our process, I have a few ideas that could synergistically improve both TOPP (I’m thinking only of TOPP labs concretely, though I think the benefits are more widely reaching) and trac as software and

community:

 * plugin maintainence/improvement:  TOPP (by which I mean, mostly me)

   has developed several Trac plugins that are widely used by both

   ourselves and the Trac community.  While the scope of a trac plugin

   is more confined than for a larger piece of software, most of these

   plugins need improvements to make them better both for TOPP and for

   the community at large.  Real time needs to be scheduled for this.

   This doesn’t have to be a primary goal, but I think not doing this

   or doing it in an half-hearted way is equivalent to abandoning

   these plugins and abandoning our stake in the trac community.

 * isolate TOPP trac needs and answer them:  I’m including

   projects.opengeo.org in this list assuming that infrastructure is

   available for TOPP labs personel to take opengeo work.  So far most

   of what I have done for our trac instances have been done only well

   after the problem has become a blocking issue for several key

   people.  This hasn’t been done out of neglect or malice, but

   because there has been no meaningful dialog on what we want our

   infrastructure (pointed here to trac) to be like and I refuse to

   guess.  This problem needs to be surmounted. Firstly, what we want

   out of trac needs to be clearly defined in such a way

   that can be easily prioritized, scheduled, and clarified.  Once

   this is done, we can start making our trac projects not just

   better, but awesome.  I think this can make a huge difference.

 * improve trac: trac is pretty awesome, but it does have some serious

   deficiencies.  Likewise, there are features that could be added to

   make it much smoother, in accordance to the idea of what trac is.

   This could be anything from new plugins, to things like TracLegos

   and supporting software, to taking out branch work in the effort to

   improve trac core.  As always, what is done here should be

   moderated by what our direct needs our and what place we want to

   take in the trac community.

These three things are conceptually the same from the mindset that these yield improvements both along the axis of improving TOPP’s process (on the technical side and policy side) and that of improving Trac and our ties to that community.  These three things are separate in the sense that in order for any of them to happen, time has to be allocated to each of these goals.  There ain’t no free lunch.

All of this also ties in to DevCenter work.  Questions about the DevCenter have usually been framed in such a light as, “Why does TOPP need a DevCenter?” as if the DevCenter is a new piece of software.  In a sense this is true.  But ultimately, the DevCenter is a blanket project that ties together (among other things) our Trac needs (as outlined above) in a coherent way that enables us to use and mold process more efficiently.  I won’t go into technical details here, but to me the DevCenter has always been more about figuring out what process we want and to implement that in a coherent and configurable

way.  Why write new software when you don’t have to?

It seems like from this text that I am heavily invested in Trac. While I believe that Trac is the right choice for TOPP, the scope of my investment is defined by what priorities are handed to me, so in that sense I am invested very little in Trac.  We have many Trac instances and projects.  We have much expertise in Trac.  Trac is open source software with a strong community, which I’m not sure how important that is to TOPP’s objectives, but its a huge plus for me both technically and idealistically.  The prioritization that I would wish is an organic growth out of the investments that have already been made (wisely, IMHO) now that we are getting returns on them.  In my observations, many of our process and infrastructure decisions have been made reactively.  We could do nothing, and devote time to maintaining the infrastructure we have now (this time loss is unavoidable, though because its unscheduled it somehow seems more forgivable).  Or we could devote resources (e.g. my time) to actively assessing and tackling these needs.  That isn’t my decision to make. But I do hope that can move beyond the point of discussing process and infrastructure to actually producing it.

I’m much better at writing for the public than writing for TOPP.  What’s up with that?

The question mark is genuine… really: what’s up with that?

­­­

­­­­­­Inspired by Doug, and the fact that I’ve promised myself that I’d blog more this year, here’s my much-delayed return to blogging.

I’ve been thinking a lot about the importance of consistency and predictability in terms of software usability, specifically with respect to Xinha. Web-based WYSIWYG editors face particularly tough challenges when it comes to consistency, since they must deal with a slew of cross-browser (and cross-browser version) incompatibilities, quirks, bugs, or whatever else you what to call all of the little and not-so-little issues that arise when trying to write modern web applications.

If cross-browser inconsistencies are bad, intra-browser inconsistencies — that is, user-facing inconsistent behavior in the same version of the same browser — are really bad. To make things concrete, here’s an example of what I’m talking about: bolding text. This is an exceedingly basic task that any rich text editor is going to need to be able to handle. Yet as far as I know there is not yet a single online WYSIWYG editor that handles bolding both consistently and properly.¹

This issue stems from the fact that visual text selections do not have a one-to-one mapping to ranges in the DOM. For example, consider the following text as rendered in a browser:

The markup for this snippet looks like this:

Now, imagine that a user selects the second occurrence of the word “this” in the sentence as follows:

And this is where the trouble starts. Depending on how the browser has chosen to ha­ndle selections, this selection could actually correspond to either of two different ranges in the DOM. The core question is whether or not the selection includes the opening STRONG tag. If it does include the tag, the selection looks like this:

Alternatively, the range could include the tag:

(If the selection extended to the end of the sentence, the situation would be even worse, since the range could include or not include the closing tag. In this case the visible selection could map to up to four distinct ranges.)

Now, for many cases minor discrepancies like these do not matter. However, there are several where these differences greatly affect how the application actually works.

For instance, if the user proceeds to type a word to replace the selection, the outcome will be different depending on the boundaries of the range.² For example, in Xinha, TinyMCE, and Google Docs under Firefox 3 and IE 7, the behavior is “correct” in that it does what I think most users would expect: The resulting word is still bold. That is, if the user types “THIS” the resulting markup is,

Safari, however, produces the following markup:

Another place where this issue crops up is cursor placement. Continuing with our example above, if a user puts the cursor at the beginning of the bolds section (i.e., just before the first bolded letter), the expected behavior is to not bold whatever the user types next. If on the other hand he places the cursor after the final bolded letter, the expected behavior is that the text typed at that point is bolded. Unfortunately, the behavior is inconsistent and sometimes unexpected. For example, Firefox shows consistent behavior, however, it is anything but obvious to novice users or those unfamiliar with HTML markup. Firefox determines whether the cursor is inside or outside of the tag depending on how the cursor got there. Approach an opening tag from the left (e.g., by using the arrow keys), and it will be outside of the tag; approach the opening tag from the right, and the cursor will be inside the tag. This means it’s possible to press the left arrow key and then the right arrow key and end up in the same visible location but in a different point in the DOM.³

The issue here is that in order to know what will happen when you start typing, you have to know something about the past — you have to know how the cursor got to be where it currently is. There is no way to know whether your text will be bold simply by looking at the ­current state of the editor.

None of these issues are deal-breakers; there are ways around all of them, and users tend to discover such workarounds over time. My concern is that the cumulative effect of all of these little annoyances is significant: It puts an undue burden on the user (to remember if/when the editing behavior differs from the rest of her computing experience, and to know how it differs between browsers if she switches or uses a friend’s computer), and it subtly teaches people to distrust the software. As I’m primarily interested in writing software that people will love — and I would argue that it’s nearly impossible to love a program you can’t trust — I think these “minor” issues are actually real barriers. As such, I’m hoping that after getting the upcoming release of Xinha out the door, I will be able to spend a real amount of time ironing out these inconsistencies. The result will I hope not just better software, but more enjoyable software.

­

1. Note that by “properly” I mean “how the vast majority of users expect things to work.” Realistically, this means — for better or worse — working the way that Microsoft Word works and most other word processors work.
2. Unless, of course, the editor’s developers have made a special effort to take these distinct cases into account and alter the browser’s default behavior if it differs from what they want it to be.
3. Note that this behavior is not a “bug” in Firefox, since it is sometimes helpful to be able get in/out of a tag. However, that does not mean that this isn’t very confusing to users, and inconsistent with most of their experience using other types of rich-text editors.

­