We all know that file operations like renaming, deleting or creating files and folders is a must and there’s nothing to discuss about them, but there were plenty of requests to enhance how we work with projects as well, and that’s what I’d like to take a closer look at.

Let’s start with the mockup of the user interface:

Sidebar works as an accordion having one item opened at a time. It contains your active project (1), some favorite projects (3) and All Projects bar (4).

All Projects bar will show list of all projects you have opened. You can remove, rename or make favorite (using a star) any of them. A favorite project will show in the sidebar as a separate item (3) to be easily accessible. To remove a project from the sidebar you will just click on it’s star icon (3). (The drag and drop functionality will also be involved.)

Sidebar shows one special case. When you open a project that is not starred (2) and then close it, it will not stay in the sidebar. However, you can star it to keep it there.

To keep things simple only one project can be opened at one time, so that other project-specific features will remain functional. A typical example would be Quick Open which filters project, recent and opened files. There are also other project-specific features planned.

Almost all of the web frameworks have a deep folder structure with plenty of files per project. However, to develop an application you usually don’t care about all of them. For example, in Ruby on Rails, you are mostly interested in:

• app/controllers folder
• app/views folder
• app/models folder
• public/javascripts folder
• public/stylesheets folder
• database.yml file

So it would be handy to have only these visible in the project. The project management now involves something we call virtual folders (5) which is basically a container designed to group and organize files and folders in your project (6). The project itself is now a virtual folder as well, so you’re ready to drop your stuff instantly.

As we are mixing physical folders and files with virtual folders, there must be some rules to keep things useful and clear. You can add physical folders, files, or even another virtual folders into a virtual folder. However, you cannot add a virtual folder to a physical one, as a physical folder mirrors folder structure on the drive and is automatically updated when the structure changes.

Intype will keep your projects in it’s configuration files until you decide to save them elsewhere. Once you do it, Intype will just remember the new path for the project and continue to use it seamlessly.

The general idea behind each feature was to have things as complex as user wants them. You don’t have to use multiple projects, stars or even don’t have to save your projects to keep your organization. That’s what I like about it.

I’m looking forward for your ideas and questions, so we can tune the thing before it’s finalized and sent for testing.

I would like to send many thanks to Andre Medeiros and Benjamin Beirnaert (sorted alphabetically), who were deeply involved in the design.

Our original release date has been moved forward several times. Mostly because we went back to the beginning, which we are not much proud of. The wait is long and it is not helping us, nor you. We learned our lesson, and believe we’ll make it through and make it right.

To the point: We finally managed to send the testing release to a bunch of guys, who I named “shadow community” and ate a lot of criticism for that, which I deserved. Guys being our testers are our friends who were involved in the development for a very long time. We found it easier to “manage” a smaller group of first-liners that would catch most of the critical bugs, than to involve whole community after this long wait.

With the guys we’re trying to test incrementally; by target parts. There are three phases of the testing planned:

1. Editing and UI
2. Bundles
3. Project

The list starts with Editing and UI which has been completely rewritten and therefore requires the most of our attention. Once the testing is done, we’re ready to involve everybody to find more sophisticated bugs.

Current state is that Intype is unstable and not feature complete. It’s being finalized and polished during the testing and bug fixing.

At the moment we’re working on the bundle management. The first version of bundle editing workflow came to be very dangerous to use. The general issue was “when to apply changes”. We decided to save changes automatically without asking user for approval, which turned out to be a very bad decision, even with option to revert changes. Now we have nice Windows-like workflow with an Apply X changes button which does the job. Fortunately changing it was much easier than we thought, so we hopefully get to the “Bundles” testing phase next week.

As for the project management, I will describe it in detail in the next post to follow.

Luckily, Martin is a big fan of Twitter, so everytime he completes some task for the release, he tweets about it. So to get the latest and instant status updates feel free to follow the Intype tweets.

By the way, there are some cool screenshots from this morning on our Twitter, so go ahead and check them out. I really love it and can’t wait for the release. Can you? :)

So what’s new with the web? Well, almost everything. The website will get a brand new, fresh redesign, a new structure as well as a complete new backend system, written from scratch in Ruby on Rails.

New structure

The structure of the website will change a bit, to better fit the need for information for a new user, as well as for the daily user of Intype:

• Homepage - a compilation of all the important stuff going on
• Blog
• Screencasts - after the 0.3.5 release there will be more and more of the magic moving pictures of Intype features
• Releases - perhaps the most important section. This will be the place for all stable and unstable releases and their release notes.
• Manual - here you will find a complete documentation of Intype and its features. This is where you send your friends asking about how things work in Intype and say “RTFM” :)
• Community - a light alternative to current Intype forums. This is the area where the community will meet, share ideas, feature requests or report bugs
• About - the team, history, the filosophy of Intype and stuff like that

New looks

A few pictures are more than a thousand words, so here’s how the whole thing will look like.

Note that these images are not tuned to perfection yet (text constrast, font sizes, etc.) and are being constantly improved in monthly iterations as the site is being build up (I hate Martin for this).

Homepage

Blog

Manual

• Built-in bundles vs. user bundles
• Bundle editor
• Grammars and injections
• Parser

Built-in bundles vs. user bundles

As you may know, Intype has two bundle repositories: built-in one stored in /bundles and user one stored in /user/bundles. Built-in bundles are those you will get with the installation. Every installation package is overwriting the built-in repository so you’ll loose any changes if you won’t back it up before re/installing. The same will happen when bundle updater is implemented once our new site gains the feature. To protect your changes, Intype is also looking into user bundles repository. There is a simple rule that items in user repository have greater priority than in built-in one.

This results that you can override any built-in bundle or item without touching them. And this is where the changes were done. Previously, we have used path comparing to know which item is overriding which, but this was OK for times without fully functional bundle editor. Now every item is obliged to have it’s unique ID number. If there are two items with same ID: one in built-in folder, and one in user folder, then the user one wins and is installed. However, thanks to the bundle editor, you won’t have to care.

Bundle editor

As the new override rules were implemented, we started working on the bundle editor. The main advantage of the bundle editor now is that it’s using Intype’s native editing component not only allows syntax highlighting, but also using all the navigation commands, and snippets as well (yes you can use snippets when editing snippet or anything else in bundle editor).

Next important thing is that the bundle editor also allows editing of the source files of the items, which might be handy when there are errors on Jasmine level, or when the developers will decide that they’ll do fancy editors for the next release.

Grammars and injections

Fixing stuff and updating grammars was next big step. Due to caching, we’re going to introduce to speed up the loading process, we had to split the grammar compiler to smaller steps to be able to recompile grammars from a binary file (the cache). We’ve also changed how grammars are now handled to support our perhaps biggest feature for parsing: injections.

Until now, if you wanted to create for example HTML grammar that supports eRuby (Rails views templating), you had to go to HTML grammar and change it to allow transitions to Ruby. Injections allows you to create a grammar that has HTML in it’s base, but injects transitions (<% ... %>) to Ruby code. All without touching either HTML or Ruby grammar. We will describe the details in the documentation we’re also working on at the new site.

Although this feature will be experimental for few weeks, we have more plans with it. One of those is to enable injections of keywords. For example, if you’d like to have highlighted methods from Prototype JavaScript library, you don’t have to change the core JavaScript grammar, but create a new grammar, include the JavaScript and then just type keywords to be injected. The same goes for injecting JS with jQuery, Ruby with Rails, PHP with CakePHP, and even XML with XHTML.

Parser

Actually the feature we’re celebrating now the most, is that we finally have new and beautiful parser management. This piece is intended to manage parsing threads with pretty smart prioritization and smart reparsing policy. Among this, Intype gained readiness for your multi-core processors as well as possibility to use all the cool features in the dialogs like search dialog (highlighting in regular expressions and format strings) and bundle editor (highlighting of Jasmine source and snippets).

Our pipeline

As we’re getting close to the release, we have also gave the higher priority to documentation and new site projects, that are required to be launched (at least) with beta (0.5). We’re all kept busy with finalizing and polishing the stuff as the internal testing phase should start in couple of weeks. Next week, Ivan will tell you more about what the new site project is being about and reveal the new design. So here’s the short list of tasks in our pipeline:

• Martin: Finalize bundles management, finalize project files management, recover the search features, help with new site, work on documentation in parallel
• Juraj: Finalize the parser management, implement file change watcher, get back to JavaScript support (for next release)
• Ivan: New site

• Status bar is combining the status area (caret position and current status of application) and a toolbar band. Yes there’s an all-mighty rebar, but its default visual appearance on Vista does not differ between static text and buttons.
• Sidebar has never been defined as a standard component, except for a docked tool window which is simply ugly.
• Tabs require better visual feedback on drag & drop; custom stuff such as Open last session or an icon for opening a new file.

It might seem simple if you consider Intype in a context of one version of Windows and a single pre-defined theme, but many users have their own favourite Windows version and their own favourite themes installed and that’s where a poor developer is going cuckoo.

So we stopped fighting and hacking the Windows themes, got rid of what we subjectively consider ugly and made it our way. We made a lot of work to deal with various colour schemes your theme might use. We simplified all the controls on the main window by using just a single UI pattern for the tab, status bar button and the sidebar window header.

OK, enough words, take a peek at following screenshot and let us know what do you think.

This new feature provides the ability to:

• Open a new file by dragging some text in Intype and dropping it on the tab-bar.
• Open a new file by dragging some text from any other application and dropping it on the Intypes tab-bar.
• Drag and drop selected text from Intype to any other application.

The ability to drag and drop a selection within a document itself is not implemented yet, but is planned for the upcoming release. You can take a look at how it works in a short screencast:

• Text Drag and Drop

We also plan to submit more screencasts as the features get stable. So stay tuned and see you in a week.

Paired characters is a feature that completes right character if you type left one. For example if you type left bracket, it will add right one. Feature also supports smart overtyping, that will just skip the right character if you entered it yourself. Thanks to the bundle management, you are of course able to configure them yourself within the bundle editor. Configuration is scope-based, so you can allow angle brackets in HTML, but not in PHP, etc. And of course, if you select something and hit the left bracket, the selection will be wrapped with the pair.

Tab triggering scheme has been updated to better cover various lengths of triggers. We also plan to add an optional word-boundary checks that will allow you to limit the tab trigger just for a complete word.

Another update has been done for the conflict selector. The conflict selector is shown when you hit a shortcut (or tab trigger) that is mapped to multiple commands (for example a doctype tab trigger in HTML). Old one has been using the standard menu component, where the new one will use a filtered list and will show the default shortcuts, the tab triggers, as well as where does the command come from.

As we plan to move to beta shortly after 0.3.5, we have also finished our licensing library, which will be tested until we reach the final stage. The beta license will be available for everyone and for testing purposes will be valid for 3 months (not a final word), after which you will get a new one.

Now we are working on attaching the undo, and some of editing quirks to have available most of what we need to test.

Spans allows us to split the document into an virtual fully automated tree. The feature allows us to unify all the required automation we’ve all wanted in a layered manner. With current model of stacked behaviors we were not able to layer the automation effectively (i.e. having paired character automation within a snippet).

This new functionality also affects the undo/redo which is now able to contain the information about serialization and restore it. So you can return back to snippets edited in past through undo.

The advanced highlighting system allows us to also highlight active spans within current context which enormously affects overal usability of the automation. This video shows multiple snippets within multi-insertion using spans.

New in the current development. We’re finally finishing last tasks for the first internal testing launch of 0.3.5. As whole UI backend has been replaced with our UI framework, we expect a little longer testing phase.

Why so slow?

Intype is being developed during the nights and mornings because of our daily jobs. This lack and irregularity of the time is taking its price, we all as users are paying. Our reason for need of daily jobs is to have income from different source, so we can keep Intype free of charge during its development process. Many users are comparing Intype’s development cycle to other products being on some regular basis. But we simply cannot compete on this level, therefore we have to find other areas where we can prove to have better product.

Areas where we can be better are for us stability, memory efficiency, consistency and user interface which need a lot of time to be designed, thought through, tested and implemented. But the result is being constantly praised along the users community. That’s what is keeping us going, even if such development is taking too much energy and health price. Actually surgery I’ve underwent four weeks ago is one of those. But don’t worry, I’m much better, because of opportunity to do what I enjoy the most: Intype.

These reasons of course disables us to give estimations, because we can almost never predict what will happen and what effect it will have on overall productivity. Sometimes it’s better idea to solve multiple problems, sometimes it’s boost in daily job, sometimes it’s other stuff. However, we constantly move forward to our primary target: to deliver 1.0 as soon as possible to be possibly able to cut off our daily jobs and spent all our time on working on most advanced features planned up to 1.9.

Releases

Currently, releases are split to two groups: stable and unstable. We decided to use these names due to their standards, but internally these groups refer to how features are completed. Actually the most recent release is much stable, consistent and feature rich than the most recent stable release. Though, some new features are unfinished. We actually are about to switch to new scheme:

• Stable: Release with finished and consistent features; run through internal and community testing.
• Cutting-Edge: Releases hot from our kitchen mostly unstable (in terms of actual stability), unfinished features and tested only internally.

Currently there are cutting-edge releases available just for few of our loyal friends, being released sometimes more than on a weekly basis. Those releases are sometimes almost not functional, giving only few areas to be tested (recently Yarden helped us to find bugs in the Hebrew text using the cutting-edge release built only for him)

The new scheme will help us spread the releases in much better way hopefully resulting in effect of more regular releases for early adopters and impatient.

Delopment Notes

However, everything has its “however”. There are times when we take a risk and leave our daily jobs for month or two to be able to boost the development of most hard parts. One of such “times” is currently pending; we both (developers) are currently taking a risk and going on full-steam. There are three team-wide priorities:

• To provide Ivan and Thomas Bell with relatively stable release to prepare the screencast focusing on working with text, files, and drag & drop features.
• To finish CP1 in relatively record time. (I’m not telling when; see above)
• To redesign and rebuild the website.