Uncategorized

As discussed in the previous post, the HTML-based UI for editing events and tasks in a tab is still a work in progress that is in a fairly early stage and not something you could use yet. (However, for any curious folks living on the bleeding edge who might still want to check it out, the previous post also describes how to activate it.) This post relates to its implementation, namely the use of React, “a Javascript library for building user interfaces.”

For the HTML UI we decided to use React (but not JSX which is often paired with it). React basically provides a nice declarative way to define composable, reusable UI components (like a tab strip, a text box, or a drop down menu) that you use to create a UI. These are some of its main advantages over “raw” HTML. It’s also quite efficient / fast and is a library that does one thing well and can be combined with other technologies (as compared with more monolithic frameworks). I enjoyed using and learning about React. Once you understand its basic model of state management and how the components work it is not very difficult or complicated to use. I found its documentation to be quite good, and I liked how it lets you do everything in Javascript, since it generates the HTML for the UI dynamically.

One of the biggest differences when using React is that instead of storing state in DOM elements and querying them for their state (as we currently do), the app state is centralized in a top-level React component and from there it gets automatically distributed to various child components. When the state changes (on user input) React automatically updates the UI to reflect those changes. To do this it uses an internal “virtual DOM” which is basically a representation of the state of the DOM in Javascript. When there are changes it compares the previous version of that virtual DOM with the new version to decide what changes need to be made to the actual DOM. (Because the actual DOM is quite slow compared to Javascript, this approach gives React an advantage in terms of performance.) Centralizing the app state in this way simplifies things considerably. Direct interaction with DOM elements is not needed, and is actually an anti-pattern.

One example of the power and flexibility that React offers is that I actually did the “responsive design” part of the HTML UI with React rather than CSS. The reason was that some of the UI components had to move to different positions in the UI when transitioning between the narrow and wide layouts for different window sizes. This was not really possible with CSS, at least not without overly complex workarounds. However, it was simple to do it with React because React can easily re-render the UI in any configuration you define, in this case in response to resizing the window past a certain threshold. (Once CSS grid layout is available this kind of repositioning will be straightforward to do with CSS.)

React’s different approach to state does present some challenges for using it with existing code. For this project at least it is not simply a matter of dropping it in and having it work, rather using it will entail some non-trivial code refactoring. Basically, the code will need to be separated out into different jobs. First there’s (1) interacting with the outside of the iframe (e.g. toolbar, menubar, statusbar) and (2) modifying and/or formatting the event or task data. These are needed for both the XUL and HTML UIs. Next there’s (3) updating and interacting with the XUL UI inside the iframe. Currently these things (1, 2, and 3) are usually closely intertwined, for example in a single function. Then there is (4) using React to define components and how they respond to changes to the app state, and (5) updating and interacting with the HTML UI inside the iframe (i.e. read from or write to the app state in the top-level React component). So there is some significant refactoring work to do, but after it is done the code should be more robust and maintainable.

Despite the refactoring work that may be involved, I think that React has a lot to offer for future UI work for Calendar or Thunderbird as an alternative to XUL. Especially for code that involves managing a lot of state (like the current project) using React and its approach should reduce complexity and make the code more maintainable. Also, because it mostly involves using Javascript this simplifies things for developers. When CSS grid layout is available that will also strengthen the case for HTML UI work since it will offer greater control over the layout and appearance of the UI.

I’ll close with links to two blog posts and a video about React that I found helpful:

It’s hard to believe it is already late August and this year’s Google Summer of Code is all wrapped up. The past couple of months have really flown by. In the previous post I summarized the feedback we received on the new UI design and discussed the work I’ve been doing to port the current UI (for editing events and tasks) to a tab. In this post I’ll describe how to try out this new feature in a development version of Thunderbird, and give an update on the HTML implementation of the new UI design. In my next post I’ll share some thoughts on using React for the HTML UI.

To try out editing events and tasks in a tab instead of in a dialog window you’ll need a development version of Thunderbird (aka: “Daily”). Since it is a development version you will want to use a separate profile and/or make sure your data is backed up. Once you have that all set up, you can turn on the “event in a tab” feature with a hidden preference. To access hidden preferences, go to Preferences > Advanced > Config Editor, and then search for “calendar.item.editInTab” and toggle it to true by double-clicking on it.

Or if that’s too much trouble you can just wait until it arrives in the next stable release of Thunderbird/Lightning. In the meantime, here’s what it looks like (click to enlarge):

The screenshot above shows the current XUL-based UI ported to a tab. I ended up not having much time to work on the new HTML-based UI (actually only a week or so) and did not get as far on it as I’d hoped — only as far as a basic and preliminary implementation, a starting point for further development rather than something that can be used today. For example, it does not yet support saving changes and not all of the data is loaded into the UI for a given event or task.

Some aspects do already work, like the responsive design where the UI changes to adapt to the width of the window, taking more advantage of the greater space available in a tab. Here are two screen shots that show the wide and narrow views (click to enlarge).

Even though the HTML UI is not ready for use yet, we decided to go ahead and land it in the code base as a work-in-progress for further development. So if you are curious to see where it stands, it can also be turned on with a hidden preference (“calendar.item.useNewItemUI”) in a current development version of Thunderbird, as described above. Again, be sure to use a separate profile and/or make sure your data is backed up.

For more technical details about the project, including some high-level documentation I wrote for this part of the code, see the meta bug, especially my comment #2 which summarizes the state of things as of the end of the Summer of Code period.

It was a great summer working on this project. I learned a lot and enjoyed contributing. As my time permits, I hope to continue to contribute and finish the implementation of the new UI. Many thanks to Google, Mozilla, and especially to my mentors Philipp Kewisch (Fallen) and MakeMyDay for their guidance and tireless willingness to answer my questions and review code. Also thanks to Richard Marti (Paenglab) for his help and feedback on the UI design work.

I wish there was another month of the official coding period to get the HTML implementation further along, but alas, so far we’ve only been able to help people manage their time, not actually generate more of it.

The clock has run out on Google Summer of Code 2016. In this post I’ll summarize the feedback we received on the new UI design and the work I’ve been doing since my last post.

Feedback on the New UI Design

A number of people shared their feedback on the new UI design by posting comments on the previous blog post. The response was generally positive. Here’s a brief summary:

One commenter advocated for keeping the current date/time picker design, while another just wanted to be sure to keep quick and easy text entry.

A question about how attendees availability would be shown (same as it is currently).

A request to consider following Google Calendar’s reminders UI.

A question about preserving the vertical scroll position across different tabs (this should not be a problem).

A concern about how the design would scale for very large numbers (say hundreds) of attendees, categories, reminders, etc. (See my reply.)

Thanks to everyone who took the time to share their thoughts. It is helpful to hear different views and get user input. If you have not weighed in yet, feel free to do so, as more feedback is always welcome. See the previous blog post for more details.

Coding the Summer Away

A lot has happened over the last couple months. The big news is that I finished porting the current UI from the window dialog to a tab. Here’s a screenshot of this XUL-based implementation of the UI in a tab (click to enlarge):

Getting this working in a really polished way took more time than I anticipated, largely because the code had to be refactored so that the majority of the UI lives inside an iframe. This entailed using asynchronous message passing for communication between the iframe’s contents and its outer parent context (e.g. toolbars, menus, statusbar, etc.), whether that context is a tab or a dialog window. While this is not a visible change, it was necessary to prepare the way for the new HTML-based design, where an HTML file will be loaded in the iframe instead of a XUL file.

Along with the iframe refactoring, there are also just a lot of details that go into providing an ideal user experience, all the little things we tend to take for granted when using software. Here’s a list of some of these things that I worked on over the last months for the XUL implementation:

when switching tabs, update the toolbar and statusbar to reflect the current tab

ask the user about saving changes before closing a tab, before closing the application window, and before quitting the application

allow customizing toolbars with the new iframe setup

provide a default window dialog height and width with the new iframe setup

display icons for tabs and related CSS/style work

get the relevant ‘Events and Tasks’ menu items to work for a task in a tab

allow hiding and showing the toolbar from the view > toolbars menu

if the user has customized their toolbar for the window dialog, migrate those settings to the tab toolbar on upgrade

fix existing mozmill tests so they work with the new iframe setup

test for regressions in SeaMonkey

In the next two posts I’ll describe how to try out this new feature in a development version of Thunderbird, discuss the HTML implementation of the new UI design, and share some thoughts on using React for the HTML implementation.

As you can see on the Event in a Tab wiki page, I have created a number of mockups, labeled A through N, for the new UI for creating, viewing, and editing calendar events and tasks. (This has given me a lot of practice using Inkscape!) The final design will be implemented in the second phase of the project. So far the revisions have been based on valuable feedback from Paenglab and MakeMyDay (thanks!), and we are now seeking broader feedback from users on the latest and greatest mockup “N” (click to view full size):

Event in a Tab, UI Design, Mockup “N”

Please take a look and send any feedback, comments, suggestions, questions, etc. to the calendar mailing list / newsgroup where we will be discussing the design, or you can leave a comment on this blog post, send a private email to mozilla@kewis.ch, or reach us via IRC (in Mozilla’s #calendar channel).

Here are some notes and details about the behavior of the proposed UI that are not apparent from a static image.

The mockup is intended as a relatively rough “wire frame” to show layout and it only approximates spacing, sizing, and aesthetic details. Unless otherwise noted, functionality is the same as in the current Lightning add-on.

A responsive design approach will be used to implement this UI in HTML. As the window expands horizontally, the elements will expand with it up to a breakpoint where the two-column “tab” layout goes into effect. Then the elements will continue to expand in both of the columns, up to a certain maximum limit at which they would expand no further. (Having this limit will keep things more focused on very wide monitors/windows.)

For vertical scrolling in a tab… Categories, Reminders, Attachments, Attendees, and Description can expand to take up as much vertical space as necessary to show all of their content. In most cases, where there are only a small number of these items, there will be enough room on the page to show them all without any scrolling. In less common cases where there are many items, the content of the tab will grow taller until it no longer fits vertically, and then the whole tab will become scrollable. (The toolbar at the top, with the buttons like “Save and Close,” will not scroll, remaining in place, still easily accessible.) This approach makes it possible to view all of the items at once when there are many of them (instead of having smaller boxes around each of these elements that are each independently scrollable). This “whole tab scrolling” approach is how it works in Google Calendar.

For vertical scrolling in a dialog window… When the contents of the tabbed box (Reminders, Attachments, Attendees, and Description) becomes too big to fit vertically, the tabbed box becomes scrollable. (Suggestions are welcome for the name of the “More” tab in the window dialog.)

The mockup shows the new date/time picker that is being developed by Mozilla. It remains to be seen whether it will be available in time for use in this project. Another possibility is the date/time picker developed by Fastmail.

Progress Report on Coding

Besides working on the design for the UI, I have continued to work on porting the current event dialog UI to a tab. I created a bug for this part of the first phase of the project, posted my first work-in-progress patch there, and am now working on the next iteration based on the feedback.

This work includes refactoring the current event dialog’s XUL file into more than one file to separate the main part of the UI from its menu bar, tool bar, and status bar items. This more modular arrangement will make it possible to make the menu bar, tool bar, and status bar items appear in the correct places in the main Thunderbird window when displaying the UI in a tab. This will solve the problem of the doubled status bar and menu bar in my first patch.

The next patch will also have a hidden preference (accessible via “about:config” but eventually to be added to Lightning’s preferences UI) that determines whether event and task dialogs are opened in a window or a tab by default.

So overall, things are progressing well, which is a good thing since there is only about a week or so left before the GSoC midterm milestone, and the goal is to have phase one of the project completed by that point. After I have finished this initial “phase one” patch, and any follow-up work that needs to be done for it, we will reach a decision about whether to use XUL, Web Components, React.js, or “plain vanilla” HTML for the implementation of the new UI design, and then start working on implementing it.

Today is the first day of the “coding period” for Google Summer of Code 2016 and I’m excited to be working on the “Event in a Tab” project for Mozilla Calendar. The past month of the “community bonding period” has flown by as I made various preparations for the summer ahead. This post covers what I’ve been up to and my experience so far.

After the exciting news of my acceptance for GSoC I knew it was time to retire my venerable 2008 Apple laptop which had gotten somewhat slow and “long in the tooth.” Soon, with a newly refurbished 2014 laptop via Ebay in hand, I made the switch to GNU/Linux, dual-booting the latest Ubuntu 16.04. Having contributed to LilyPond before it felt familiar to fire up a terminal, follow the instructions for setting up my development environment, and build Thunderbird/Lightning. (I was even able to make a few improvements to the documentation – removed some obsolete info, fixed a typo, etc.) One difference from what I’m used to is using mercurial instead of git, although the two seem fairly similar. When I was preparing my application for GSoC my build succeeded but I only got a blank white window when opening Thunderbird. This time, thanks to some guidance from my mentor Philipp about selecting the revision to build, everything worked without any problems.

One of the highlights of the bonding period was meeting my mentors Philipp Kewisch (primary mentor) and MakeMyDay (secondary mentor). We had a video chat meeting to discuss the project and get me up to speed. They have been really supportive and helpful and I feel confident about the months ahead knowing that they “have my back.” That same day I also listened in on the Thunderbird meeting with Simon Phipps answering questions about his report on potential future legal homes for Thunderbird, which was an interesting discussion.

At this point I am feeling pretty well integrated into the Mozilla infrastructure after setting up a number of accounts – for Bugzilla, MDN, the Mozilla wiki, an LDAP account for making blog posts and later for commit access, etc. I got my feet wet with IRC (nick: pmorris), introduced myself on the Calendar dev team’s mailing list, and created a tracker bug and a wiki page for the project.

Following the Mozilla way of working in the open, the wiki page provides a public place to document the high-level details related to design, implementation, and the overall project plan. If you want to learn more about this “Event in a Tab” project, check out the wiki page. It contains the mockup design that I made when applying for GSoC and my notes on the thinking behind it. I shared these with Richard Marti who is the resident expert on UI/UX for Thunderbird/Calendar and he gave me some good feedback and suggestions. I made a number of additional mockups for another round of feedback as we iterate towards the final design. One thing I have learned is that this kind of UI/UX design work is harder than it looks!

Additionally, I have been getting oriented with the code base and figuring out the first steps for the coding period, reading through XUL documentation and learning about Web Components and React, which are two options for an HTML implementation. It turns out there is a student team working on a new version of Thunderbird’s address book and they are also interested in using React, so there will be a larger conversation with the Thunderbird and Calendar dev teams about this. (Apparently React is already being used by the Developer Tools team and the Firefox Hello team.)

I think that about covers it for now. I’m excited for the coding period to get underway and grateful for the opportunity to work on this project. I’ll be posting updates to this blog under the “gsoc” tag, so you can follow my progress here.

I have noticed a few reports that Lightning 2.6.4 is not working with the Debian variant of Thunderbird, called Icedove. Together with one of our users (thanks Arie!) this was reported to the Debian package maintainers.

There are slight differences in how Icedove and Thunderbird are compiled, the result is that the Linux symbol versions required are different. The maintainers are working on fixing this, in the meanwhile all you need to do is make sure you are using only one source for the packages:

If you are using Thunderbird from mozilla.org, make sure you are using Lightning from addons.mozilla.org. You can install it into /opt if you don’t want to conflict with your Debian packaging system.

Unfortunately, this difference in compilation has cost us some negative reviews. If everything is working for you or this post has helped you to use the right versions, please show some love and write a review ♥.

This is the moment I have been waiting for so long! I can’t say this big enough because I am so excited:

Check out this awesome:

The new site is clear and concise. Not too many links, all important links on one page. The download button gives you the latest version directly from addons.mozilla.org.

There are some features still lacking that we will be adding in later, it was more important to just get this thing out in the open first. The holiday calendars page is still missing. Ideally the new holiday calendars area will auto-generate itself from the existing holiday files. We also wanted to show the most recent blog headlines.

The new site is part of bedrock, Mozilla’s shiny new website framework. This means we get a lot of stuff for free, one of them is localization. I haven’t found out how this works yet, but it will be possible to translate the page into any language.

Google has decided to change the authentication mechanism for their CalDAV calendars to OAuth, which required some changes in Lightning to accommodate.

Due to these changes, the URL to access the calendar has also changed. The old endpoint will stop working after September 16th (today!). This affects only Google calendars using CalDAV protocol.

Calendars using the Provider for Google Calendar or iCal read-only access won’t be affected.

How do I know if I’m affected?

Open your calendar’s properties by right-clicking on calendar name and check if the location starts with https://www.google.com/calendar/dav/. If it does, you are using CalDAV and need to set up your calendar again with the new URL.

How do I set up the new calendar?

To use the new CalDAV Endpoint, you will need Lightning 2.6 and Thunderbird 24, which will be released tomorrow, September 17th. There will be a blog post on the release tomorrow, so please use the navigation to view the new post when its there to get the download links. Anyway, here are the steps:

Download Thunderbird 24 and install Lightning 2.6

Open the new calendar dialog (File → New → Calendar)

Add a new remote calendar (On the Network → CalDAV)

As a location enter the following, be sure to replace your email address:

More details on how to set up from Google can be found here. After setting up new calendar you can safely remove the old one from Lightning. This will only remove it from calendars list, your events will not be deleted from Google’s servers.

But I want it to work now!

In that case, you will have to use a beta version of Thunderbird and Lightning. You can get Thunderbird 24.0b3 here and the corresponding Lightning 2.6b2 here. Please use these versions only if you really can’t wait, once the release version is out there will be no support for beta versions.

One more thing…

Its a little unfortunate that Google is shutting down the API in coincidence with the release. I’m pretty sure a few people will blame Lightning’s new version for this (understandably, since that is the only thing they knowingly changed). This will mean we will get a few support requests covered as bad reviews, I already saw one today! If you found this blog post useful, please stop by addons.mozilla.org and give us a few stars.

Update on @googlemail.com addresses

If you created your Google account with an @googlemail.com email address, you will need to use this email address in the URL, even if you’ve switched to @gmail.com now! Otherwise it will look like everything works, until you try to add/modify events. I will notify the Google folks so they can get this bug fixed on their end.

Update: Still not working? Here is why!

Unfortunately there are two more problems. First of all, you may be experiencing an instant failure, if you inspect the logs you might see an error 400. Aside from the location change, Google has also introduced support for webdav-sync. In theory this makes the synchronization process faster, but Google does not implement the fallback mechanism we rely on. We can probably fix this on our side though by updating to a newer version of the webdav-sync draft.

Next up is a bug on our side. When the OAuth token expires, there is an error refreshing the token. I will take care of fixing this for Lightning 2.6.1

But I really need it to work now!

Ok then, I have one option left for you. For the time being you could switch to the Provider for Google Calendar, an extension that uses the Google Calendar API to connect. You will have to set up the calendar a bit differently, using the new “Google Calendar” option in the new calendar wizard and the XML address as the location URL.

Lightning 2.6 is due on September 17th and will be a major release. The last stable relase was Lightning 1.9 and the only testing that has been done since is a little testing on the beta channel. I say this is not enough!

One problem we have is that a handful of locales are broken (only one bug report, by the way!). This is mostly due to some changes we had to undertake regarding the l10n dashboard, making it hard for localizers to figure out where to sign off.

If you can read a language other than English, please take a few minutes for the following steps:

After starting the app, check the error console for anything that looks bad. Warnings are probably ok. Clear the error console.

Open every dialog you know of (print, event, task, summary, preferences, calendar properties, …). Make sure it looks normal.

Set up a remote calendar of your choice, make sure you can connect.

Check the error console again if something alarming was added.

You can of course still help if English is your only language. Please do a few tests to make sure everything works. You might as well upgrade your original Lightning installation, because this is what you will receive in about 3 weeks anyway. The earlier we find issues, the higher the chance we can fix it before it reaches everyone.

I have put together a survey with a few questions on how you manage your tasks. Not only will it help me with my final thesis, it will also help me better understand how users manage their tasks.

Why it this important? The current tasks UI in Lightning is mostly a direct implementation of the technical spec. This might work for simple needs, but its far from effective for completing your tasks.

I have come up with a system that caters my needs, but as the goal is for lots of users with different needs to be able to use the system without frustration, I need to ask you a few questions.

The survey is not limited to Lightning users, everyone who has at least one task on his or her list should take a look. It should only take a few minutes to complete and most questions are multiple choice.

You can find the survey here: http://bit.ly/1cJHjaa. I will analyze the results on August 20th, so don’t forget to do this soon!

Please share, RT this tweet and tell your friends. Bonus points for finding someone who you know handles tasks quite different than you do.