Jun 222009

For obvious reasons, I keep a close eye on MindTouch’s development plans, and have been watching their planning work on the “Minneopa” release tentatively scheduled to ship in late July. This is a pretty short turnaround from the “Lyons” release that shipped just a couple of months ago, which is the one we’re currently using.

Judging from the sorts of things they’re working on as the primary features for this release, I suspect they’re doing this work for one or more specific corporate clients (other than Mozilla), since of the major work they’re doing, none of it appears to correspond to anything on our wish list. One or two of these items do look like they might be potentially interesting, but they’re not well specced out yet, so we’ll see.

However, looking in their bug database, we can find an assortment of bugs I reported that are tentatively planned to be investigated — and hopefully fixed — in the Minneopa release. Being targeted for the upcoming release is of course not a guarantee, but it’s a hopeful sign.

The things from my wish list that are tentatively slated to be worked on for Minneopa:

  • The side-by-side diff view, which currently lists the entire article side by side, which limits its usefulness, will hopefully only show the blocks containing changes, instead of the entire content.
  • The link editor dialog will hopefully get some love; it needs some!
  • Currently, if the wiki encounters timeouts while communicating with the database, it can become unreliable, even after the database returns to normal. Hopefully progress will be made on fixing this; if nothing else, they plan to complete some refactoring of the database code that should make it more reliable going forward. With luck, just doing that will help with this problem.

There are several other items that I’ve filed tickets for that they plan to look at for the Minneopa release, although they’re not on my major concerns list.

At this point, these are:

  • Currently, if the login cookie disappears while you’re editing, trying to save instead loses your work.
  • We’d like to be able to add customized descriptive text to any Special:Tags page, so we can use them as category pages that offer introductory text.
  • Special:Tags pages currently show page titles with spaces even if the titles have been overridden to use underscores.
  • The edit summary entry field is currently very narrow; they will hopefully widen it for us.
  • I’ve requested the ability to disallow the invention of new tags in the tag editing feature for pages; instead, tags will hopefully be created using a separate interface accessible to certain trusted users, and when tagging articles, users will only be allowed to use pre-defined tags. This will hopefully improve the validity and usefulness of tags by ensuring that tags are used more consistently.
  • Currently, links to talk pages that have no content are rendered as normal links, instead of “no content” links. This means people will follow the links hoping to learn more, only to be disappointed.
  • The feature that lets you recover your password currently requires you to type spaces instead of underscores, even if you used underscores when creating your username. This should be fixed.
  • We requested an option to allow image and file management for articles to be handled on a separate page from the article page itself, so that you don’t have the “Images” and “Files” sections tacked at the bottom of articles. This would make the interface for people not editing the content cleaner, but I’m no longer certain we’d use this. I’d like opinions!

Hopefully more things will make their way in, but given the short schedule for this release, I don’t expect miracles. With luck, once this update is out the door, they can start working on more of our big requests!

Still, just getting the improved link editor and side-by-side views will be big wins for ease-of-use for us, I think.

And, again, keep in mind that there’s no guarantee that all of these things will actually be addressed in this release! I don’t want people whining to MindTouch (or to me, actually) if anything gets cut from this short timeframe release!

 Posted by at 3:07 PM

  6 Responses to “Mindtouch “Minneopa” planning and Mozilla”

  1. Hey Eric – Your needs are still very much at the forefront of our development processes! Your feelings are correct – most of Minneopa’s features are for feature development sponsored by other corporate entities. Our team’s been swamped with a wide range of projects as of late, and we haven’t pruned or defined the Minneopa release in stone yet (the schedule will most definitely shift back a couple of weeks). We’ll soon be taking a pass at the Minneopa bugs and your wishlist to come up with something solid soon. Thanks!

  2. Yup, that’s what I figured. :)

  3. Sounds awesome – especially knowing that they have other customers and won’t be dependent on Mozilla ;)

    Shouldn’t the make-edit-summary-wider bit be implementable as a local theme thing? (That would get the fix in faster, and hopefully easier to deploy?)

  4. The way the edit summary box is coded, I don’t see an easy way to fix it; there’s no CSS class on the input element itself, just on the div block surrounding it.

  5. Hey Eric,

    The team is currently triaging issues for the upcoming few releases now. I’ve gone through the list from https://developer.mozilla.org/User:Sheppy/MindTouch_Deki_bug_priorities – there seem to be one issue which is already resolved, and will require skinning changes in your custom skin (item #20). Issue #13 also seems resolved.

    My goal is that by next week, we’ll understand the full scope of items in Minneopa so we can commit to fixing the issues that will allow you to plan accordingly.

  6. roy:

    I presume by “resolved” you mean for Minneopa? If the RSS languages thing is already in, it would be helpful to know how to skin that.

    As for the popular pages thing, I’m pretty sure you must mean for M, since it’s definitely not filtering by language in 9.02.2. :)

This site uses Akismet to reduce spam. Learn how your comment data is processed.