It’s an exciting time to be in this area of software development. Software companies are finally turning their attention to small organizations, businesses and households; groups that are less structured than traditional corporate environments.

Chandler falls into this new category of personal and collaboration tools for small, loosely structured workgroups. There are 2 significant ways in which Chandler departs from enterprise-scale collaboration tools:

One. Traditionally, many collaboration tools have been structured around “clients” and projects, which were presumed to have start and end dates and concrete deliverables, that once delivered meant the project was complete. Delivering for each client was assumed to be a relatively “straightforward, process-oriented” affair that could be mapped out in “workflows” that remained constant from one project to the next.

By contrast, Chandler assumes that new projects (or tasks) will continuously emerge from existing projects. Old projects change or become irrelevant before they’re even begun. As a result, “work” becomes a never-ending, ever-changing procession directed towards a higher-level goal. To be sure, deadlines and milestones exist along the way. But they are markers in a continuous progression as opposed to tidy endings to bounded projects.

In short, Chandler is designed for groups that are constantly re-inventing what it is they do and how they do it.

As a result, building and maintaining project and workflow structures for managing and organizing such a constantly changing morass of tasks, dates and unresolved issues just doesn’t seem worth it.

Instead, Chandler is intended for users who are actively looking for something that lets you stay “organized” at their own pace. They specifically don’t want to feel like they’re being pressured to set deadlines they’re not ready to set. They don’t want to be harassed about tasks you entered but no longer need to do. In other words, Chandler users want a “Don’t call me, I’ll call you.” kind of tool.

Two. Traditionally, collaboration tools have focused on coordinating hand-off of information and shared resources (documents, media, etc) so that each member of the team has access to what they need in order to focus on their work.

By contrast, Chandler assumes that ownership of responsibilities is shared and passed from one member of the team to another with relative fluidity.

As a result, Chandler sharing isn’t modeled as a fileshare that gives everyone access to everyone else’s work. Instead, Chandler collaboration assumes that people need help working on the same thing together.

Sharing in Chandler is less about “watching” other people’s task lists and calendars and more about sharing a group collection and calendar where individual tasks are passed around or simply worked on in parallel by multiple people.

This doesn’t mean that “personal” collections can’t and shouldn’t be shared with others. It’s more a matter of “What is Chandler’s special sauce?” when it comes to collaboration.

This fluidy in collaboration also explains why Chandler is first and foremost a personal tool with built-in collaboration as opposed to straight-on groupware.

Our belief is that the line between “my work” and “your work” and “our work” is now sufficiently blurred such that tools that draw a hard line between personal and group task management simply erect unecessary hindrances that break common workflows.

Note: This is yet another way in which Chandler aspires to mimic email. People see email first and foremost as a personal tool. But fundamentally, email is about communicating and working with others. Nevertheless, the collaboration aspect of email is framed as an extension of the personal.)

Use Case: Setting up and Following-thru on a Meeting.

Edit, Evolve, Send and Re-Send the same item of information as your task to schedule a meeting turns into an invitation turns into a scheduled meeting on your calendar turns into an agenda list turns into meeting notes.

A simple meeting can often generate a dozen or more separate bits of information for everyone involved; bits of information that each person then needs to manage independently.

• You create a task item to schedule a meeting;
• Send out a separate email message to invite others to the meeting;
• Follow-up with a whole thread to work out the meeting agenda;
• And add the meeting to your calendar.

• As the meeting shifts around and the agenda changes (all information that arrives via more email messages), you update the event on your calendar.

• During the meeting, you write up notes and send them out in yet another email; which in turn
• Prompts responses as others amend your meeting notes in follow-up emails

When you go back to look for the definitive record of what was discussed and decided at that meeting, where do you start? There are so many bits to collate and reconcile into a “single source of truth”.

By contrast, in Chandler you have 1 item that you edit and amend over time with changes and new information.

Your task to schedule a meeting can be sent out as an invitation email and then put on your calendar once everyone has agreed to a suitable time. In parallel, you can pull together a meeting agenda on that same meeting event item. During the meeting, you can take meetings notes, again in the same meeting event item. All the while, you can send and resend the same task/event item to notify people who aren’t sharing through Chandler.

1. Collecting Agenda Items for a Meeting in a “Task List” View

2. Reviewing Meeting Notes from the Calendar

3. Sending an Update to the Event with Notes from the Meeting

More importantly, all of this use and re-use is plausible because you can access the same information item from different contexts (the calendar and the list view, multiple collections) and there is built-in support for “losing” and “finding” information. Otherwise, recycling and evolving notes and events would quickly turn into an onerous workflow you would not bother with.

In Chandler:

• Meetings on your calendar can be managed like tasks in a list view; and vice versa,
• Tasks can be tracked from the list view *and* put on the calendar to mark important deadlines and milestone dates;

• The LATER “Triage Status” allows you to “disappear” stuff you can’t deal with right now without losing it forever;
• Tickler alarms and event dates automatically re-focus your attention on things you need to follow-up on

This Recycling Workflow works for maintaining lists (shopping lists, lists of questions, thank you notes, etc) and working on drafts as well. Really, it applies to anything that evolves and changes over time.

Reducing sidebar organizational clutter: In Chandler, you get 9 different views of your data for every 1 Chandler collection you create.

• In the sidebar, you can generate 3 views of your data for every 1 collection you create. For example, rather than having a Home Calendar + Home Task List + All Home Stuff, you create 1 Home Collection and slice and dice it by navigating the Application Areas in the Toolbar.
• Within each collection, the 3 Triage Status sections give you 3 more ways to slice and dice each collection/application area.

Reducing duplication of information between your email, task list and calendar. In Chandler, you can:

• Manage calendar events as tasks in a list; and vice versa, you can
• Manage tasks by putting putting them on the calendar to mark important deadlines and milestones
• Address any item and send it out as an email

Reducing the # of information bits you generate by recycling your data with Triage Status, Tickler alarms and integrated Calendaring.

You can use and re-use your information items in Chandler by continuously editing and evolving a single item over time, even turn into a completely different kind of item.

Here’s a task to re-schedule a dentist appointment that turned into the new appointment on the calendar. This item originally started out as a confirmation email from my dentist, which I moved into Chandler and re-purposed as a reminder to re-schedule my appointment.

Sending, Editing and Re-Sending Email

With email, once you’ve sent a message, you can’t edit it anymore. Amendments can only be made by sending a new message. However, it’s not enough to just give people a way to keep editing a single item over time (which is what most task managers do).

Yet, one of the reasons email is so appealing is precisely because we can forget about everything that’s come before. Every new message is tabula rasa. There is a natural rhythmic cycle to work. We make a little bit of progress. We get stuck. We stop thinking about it for a while as the issue percolates in the nether regions of our brain or as we wait for someone else to get back to us. And then we pick it up again. In the meantime, email’s great at helping us “forget” about problems we can’t make progress on. The problem is, once you’ve lost something in email, it’s hard work to get it back.

Nevertheless, any effective alternative to email has to do a good job of disappearing and reappearing issues, in the right place, at the right time.

In Chandler, Triage Status allows you to forget about stuff (for a while) without losing it forever.

Instead of having a binary choice:

• Keep this in front of my face OR
• Lose it and forget about it forever…

You have 3 choices:

• Keep this in front of my face OR
• Keep this, but shove it off into LATER for now OR
• Lose it and forget about it because it’s DONE! or Obsolete.

You can move items in and out of your focus (NOW versus LATER) as many times as you need in order to finish the job. And if there are important deadline and milestone dates to remember, you can assign a Tickler Alarm or put the item on the Calendar and Chandler will re-focus the item for you on those dates.

Reducing duplication of information that is relevant to multiple contexts.

In Chandler, notes and events can appear in multiple collections. This means that events you and your spouse are attending together can appear as the same event on both of your calendars. Issues that need to be resolved for several projects can be tracked as the same note-item multiple project collections.

Tasks can show up in the context of a project collection and in a collection organized around a person, department or organization or a location (e.g. Things I need to discuss with Jan, HR stuff, or Home Office).

This allows you to organize your information in whatever way is most helpful to you without the up-keep of updating multiple versions of the same information.

Reduce the # of bits of information you exchange by Sharing.

This is somewhat self-explanatory. Instead of emailing back and forth, you could be editing the same lists, drafts, and meeting agendas with the people you work most closely with. When you need to alert people who aren’t sharing through Chandler, you can send (and re-send) the notes and events you’re working on via email.

These are some of the high-level design concepts. Stay tuned for a more specific scenario!

We’ve stripped out quite a bit of chrome. In many ways, the Preview release was an experiment. We threw out ideas out in order to see what would stick. 0.7.5 is what stuck.

But simplicity is more complex than that.

The changes we’ve made have simplified the interface. But there is simplicity at the workflow and information modeling levels of application to consider as well, and that simplicity isn’t new.

With a new, pared down UI, we’re hoping more users will discover the underlying simplicity at the heart of the application.

What do I mean by underlying simplicity?

There are tools that are simple at the conceptual and user interface level, but complex when it comes to workflow and information management.

Not to pick on email, but email is one of them. Email concepts are simple: Send and Receive messages. Reply-to and Forward messages. However what ensues from this simplicity is a propensity to divide and multiply; which results in the overflowing, hard to parse, hard to manage Inboxes we love to hate. Email begets more email and we’re responding with all kinds of ways to keep the onslaught under control: Auto-filtering strategies, tagging and categorization schemes and Inbox kung-fu processing techniques.

By contrast, Chandler aims to tame your inbox by reducing the volume of information bits you generate (individually and as a group).

Imagine if…

• Instead of starting up new emails every time you have a new thought on an old problem; you could keep editing emails after they’ve been sent/received.
• Instead of copying and pasting information from email onto your calendar; you could take emails and put them directly on the calendar to mark event dates, deadlines and important milestones.
• Instead of resending information to yourself as reminders; you could set alarms on the emails you already have so that they arrive again in your Inbox at the time of your choosing.
• Instead of duplicating information in order to get it into all the right places; you could file messages into multiple folders so that the same email showed up in all the contexts you need it to: Invoices, status, by project; your stuff, your spouse’s stuff, errands list, etc.
• Instead of having a forest of flagged items crowding out new messages in your Inbox; you could cordon off the things you’re working on NOW from stuff that can wait until LATER.

To be clear, Chandler still isn’t meant to replace your email application. Instead, email to us, has served as an invaluable design-model for the best and the worst in information management and collaboration. Studying it carefully is how we think we can make Chandler a compelling alternative to email. See more detailed analysis.

So, instead of scattering your thoughts across dozens of email messages, text files, calendars and task lists, try putting them into Chandler and try out some of the scenarios described above.

(Stay tuned for a more detailed analysis and an illustrative scenario of how Chandler can simplify the information in your life.)

Then of course, I immediately ran into this one.

So, is it true? Will a new generation of collaboration tools help us wean ourselves off email? (The same way IM and social networking have already weaned us off email for social interactions.)

We hope so.

Chandler is most useful when used as an alternative for all the important stuff you used to do with email.

This should be true if you’re just using Chandler for yourself. This is doubly true if you’re sharing with others because at its best, Chandler opens up an alternative, more ergonomic channel for collaboration that results in fewer bits of information to keep track of and allows the group to leverage individual efforts to manage and organize information.

However, any collaboration medium that attempts to supplant email needs to retain what’s great about email while avoiding the pitfalls that have us all reeling from overflowing inboxes.

Here are some lists of email characteristics we want to emulate and avoid in Chandler.

What we want to keep: Email doesn’t get in the way of your ideas!

1. Every new message is a blank slate. Unlike other collaboration mediums (CMSes, Wikis, Project Managers, Shared Documents) composing new email doesn’t require you to first figure out how this “new thing” fits in with everything that’s come before.
2. Email lets you tackle issues in bite-sized pieces.
   

   Bite-sized means it’s easier to get started on tackling hard problems.

   Bite-sized also means you can manage email like a task list (as many people do). This in turn helps you multi-task. You can start, develop, fork and resolve dozens of threads at the same time. You keep track of it all by flagging/filing individual messages. With email, big, intractable problems are conveniently broken down into bite-sized next actions.

3. Email lets you tackle issues from multiple angles. You can formulate and reformulate what you’re thinking in a dozen different ways, addressed to a dozen different groups of people. Again, unlike other collaboration mediums, there’s no pre-existing structure to get in the way of what you need to do. Each new message/thread exists as it’s own, independent topic of discussion.
4. Email is free-form. Email messages are all about the wide-open field of unstructured data we call the message body. It allows you to focus on what you need to communicate! Whom you need to communicate with, is the only unavoidable decision you need to make. However, with the advent of aliases (everyone@wholeoffice), even that decision is avoidable.

1. Email is universal. Not everyone is on your Exchange server. Not everyone has access to your company’s intranet. But everyone (for all intensive purposes) is on email these days. Email is the one communication medium where you’re guaranteed to get through (except when overzealous SPAM filters get in the way). Whether someone will actually absorb your communication is a separate issue.
2. Email is asynchronous. You can continue to make progress on other work as you wait for responses. This means you can work independently of your colleagues without losing touch.
3. Email keeps you up-to-date on what’s new. Every “new” piece of information is pushed to you as a new message. You never have to remember to “check-in” to find out what’s going on. You also never have to go hunting through an edited document wondering, What’s changed? Did something change?
4. Email encourages discussion. Email is linear. Each person gets their say. (However, while talking on top of one another is no longer a problem, no tool can prevent people from talking past each other.)

What we want to avoid and improve on: Email begets more email!
The very qualities that make email the defining tool of the information workplace are also its Achilles heel. Email is too easy to send. Each email in turn spawns more email to the point where you can no longer see the forest for the trees and you need to create more bits of information to keep track of the bits you’re losing in email.

1. There’s no way to “silently” make information available on an “as-needed” basis. To get information out, you have to send the email, thereby actively pinging every recipient with a message, regardless of whether you need their active attention. Ergo, we all get a lot of FYI mail, which in turn, dilutes the pool of mail that actually requires a response.
2. You can’t edit email. Once you’ve sent it, it’s done. If you forgot something, if someone else wants to add something to your list, if there’s been a change in plans, you’ll have to send a separate email. Ergo, we all get a lot of “update” emails.
3. When a mail goes out to 1 or 200 people, every recipient has to do the work of processing that email. Oftentimes, we process it in exactly the same way: Received a notice to hand in your benefit forms? Add it to the calendar. Put it in your “HR” folder. Yet, there’s no good way to distribute that work across the group. Ergo, we all spend a lot of time managing email.
4. There’s no way to add structure to email. The unstructured, blank slate that email offers when you’re initially composing the message is great for unblocking the free-flow of information. However, once you do have enough of a clue to add a bit more structure, you can’t. Ergo, email results in the creation of even more bits of information to manage as each email creates new calendar events and task items.
5. There’s no source of truth. Decisions are amended and reversed over multiple, forking threads. People are added and removed from conversations. Uncovering “the truth” in email turns out to be subjective and hard-won.

There are a dozen different ways in which Chandler strives to meet the ideal described above. We’ve already begun to see success stories of users moving their work from email into Chandler and we’re using them to help us become a better alternative to email!

Then, I came across Chris Brogan’s How I tamed my inbox. I’ve seen write-ups like this before, but this post really resonates with how Chandler is meant to be useful as a companion to email. Namely: Get important stuff out of email into a trusted system that has better affordances for managing the things you need to do. Chris Brogan’s trusted system consists of a lightweight filing system, a to-do list/project manager (Things) and a calendar (Google Calendar).

With Chandler, you get the to-do-list and calendar in one, integrated package

To quote Chris:

If any of my projects are time specific, I put that information into Google Calendar. I then set up the reminders along the way. Further, if the project is large or lengthy, I set up little milestone time frames such that I will remember to work periodically on projects all the way up to their due date.

Takeaways: Nothing gets done in a single sitting. The ability to see to-dos on a calendar is critical.

I have notes and details on a new conference I’m launching for marketers for September in the Boston area.

Takeaway: Keeping track of “notes about what I need to do” is just as important as keeping track of what I need to do.

However, I haven’t seen much discussion of sharing as a way to deal with “email overload”. Instead, too-much-email is most often portrayed as a personal information management problem.

Yet, email is first and foremost a communication tool, a way for groups to collaborate. If there’s a problem with email, it’s a group information management problem.

Ergo, sharing is very relevant to “email overload”. In addition to helping people deal with “too much email”, we can and should also be looking for ways to:

1. Reduce the amount of email we send and receive by restructuring the way information is disseminated and developed over time; and
2. Reduce the amount of time we spend managing email by sharing and distributing the work of putting information into the right contexts. (Only 1 person should ever have to do the work of putting things onto the right task lists and calendars!)

To be clear, I’m not saying that the solution is as simple as: Don’t email, just share! The point I’d like to make is more precise: Sharing is an important part of how we fix email, provided we don’t create yet another collaboration medium that simply generates more email!

Chandler attempts to walk this line and while there is always more work to do, we’ve already seen success in reducing email for our users. I will follow up with a more detailed blog post on how you can “Send less email” and “Spend less time managing email” with Chandler.

In Part 2, I will walk you through some of the discussions we’ve had on the list and my reasoning for not going down the path of providing more granular LATER sub-sections defined around time.

With users piping up about how their LATER sections were becoming unmanageable, we revived discussions around adding LATER sub-sections defined around loose timeframes:

• LATER-Next week
• LATER-In 2 weeks
• LATER-This month, etc…

and improving the sub-sort order so that items in LATER are ordered by when they’re going to happen:

• “LATER-Imminently”
• “LATER-Far in the future”
• “LATER-No date at all”

The latter (improve sub-sort) was always part of the design and is on the short list of bugs to fix after we ship 1.0.

But I worry about going down the path of more granualar LATER sub-sections. I worry about falling into the trap of over-planning, over-emphasizing the importance of defining timeframes and inadvertently pushing users to assign dates they have no intention of holding themselves to, which again, results in big piles of items getting dumped into NOW when they’re not ready to deal with them.

Instead, I think it will be more effective to automatically collect all LATER items that don’t have a specified time frame (items with no alarm, no event dates) into a separate section called “LATER - No date assigned”.*

This smaller, hopefully more manageable “LATER-No date assigned” section acts as a reminder that there are deferred items that need to be reviewed and re-evaluated on a regular basis because they’re not going to magically re-appear in NOW on their own.

To make this list even smaller, we could provide a “LATER-Not really” option for items we create for peace of mind, but actually have no intention of doing, ever.

*Being an open source project that supports plugins means that of course doesn’t stop anybody from implementing an add-on for more granular LATER sub-sections. What I’m discussing here is the out of the box experience.

That was part of our “Be all things to all people.” past.

2 years ago, we started the long process of paring down our goals and zeroing in on a single focus so that we could deliver a 1.0 product. GTD is not our single focus. Supporting knowledge work is. (Blog post coming soon.)

This doesn’t mean Chandler is somehow the anti-thesis of GTD. Given the overlap in problem space, I imagine that as we pursue our single-minded goal, Chandler will continue to improve for GTD practitioners as well.

We also welcome and will actively help volunteers who want to write a GTD plug-in. Come find us on the Chandler Development List!

However, many of our users already find Chandler to be useful for practicing GTD today. They define collections around the GTD projects list and @contexts, use the Dashboard collection as a centralized Collection Box and assign ticklers and calendar dates.

For these users, Chandler is still a better tool for GTD than say Palm or Paper, the original David Allen GTD tools.

Some of the features our GTD users have put to good use include: 

• The ability to organize items into multiple collections means you can have next actions live in multiple contexts and you can organize next actions by project *and* by context.
• Chandler’s integrated calendar and list views mean tasks you’ve put on your calendar can still show up on your next action lists as scheduled tasks or events.
• Sharing! Not something covered in GTD, but Chandler helps you implement GTD as a household or a workgroup.

Still, Chandler shouldn’t be construed as an implementation of the GTD methodology or any other methodology for that matter. We don’t believe software can teach systems the way David Allen can. 

Chandler also can’t teach users how to turn Goals into Next Actions or even to appreciate that there is a difference between the two. These are things people need to come to terms with on their own, in their own way.

As Rick Rawson explained on the Users List:

“I am finding that Chandler does not organize my life. It only helps ME organize my life. And that takes time and work. There are any number of different strategies within Chandler that can be used to be sure I don’t forget all those “things” to “research” and “think about.” None of those methods is magic; all require MY brain and my time. I have to take the time to figure out what works for ME in MY context and with MY personality and deficiencies. What I like about Chandler is that it provides me with some tools so that I can devise my own solutions.”

This is consistent with user feedback we’ve received that the GTD label actually scares people away. Even though there isn’t any GTD terminology in Chandler, people who knew about Chandler’s past association with GTD assumed they needed to subscribe to a particular way of doing things in order to succeed with the product.

But “deadlines” are one of the big downers of task managers because they are overused and misused, applied to everything as if everything could be managed in terms of time.

You enter a task. You studiously assign timeframes: deadlines, start dates and alarms. The dates are often meaningless, but you fear that if you don’t, you’ll completely forget about it. Then, when the dates roll around, you end up with a big pile of overdue tasks. You clearly cannot deal with all of them now and you still don’t have a good way to ensure that you won’t forget about them. So instead, you constantly carry around the baggage of a long list of overdue tasks. Oftentimes, overdue tasks turn into moot tasks. Stuff you never got to and then it was too late and well, looks like it wasn’t really that important. (This is perhaps the most common reason people give for why they just don’t need a task manager.) But when you first thought of the task, it would have been like pulling teeth to admit that, so you dutifully entered it and set a due date anyway.

Trying to guestimate when you’ll actually do things and how long it will take you and by when you’ll have them done, aka time management is an exercise in futility…as far as “knowledge work” is concerned.

It’s absolutely essentialy for things like dentist appointments and paying your rent. But the benefits are less clear for tasks that start with verbs like Brainstorm…Look into…Evaluate…Think about…Follow up on…

This is not to say that there aren’t hard deadlines for the end-goal of all your Brainstorming and Looking into.

And a “responsible” person would leave themselves plenty of time to brainstorm before the product of that brainstorm needs to be handed in as a concrete deliverable. But the reality is, trying to quantify how much brainstorming (3 hours) you need to do and when you’re going to do it (2 days before the write up is due) is an exercise in futility.

Which is why many people don’t bother trying to record and track these random one-off thoughts in any kind of an organized system (unless you count email as organized.) Instead, they’re strewn across desks on little bits of paper, desktops in text files, emails, sticky notes, napkins and last but not least, your brain.

The problem for a growing number of people is, there is too much of this “stuff” to keep track of in your head and still no good way to keep track of them outside of your head. Traditional task management solutions designed for “concrete” tasks are too structured. Not very structured solutions like paper notebooks and text files are well, not very structured.

Chandler attempts to walk the line by offering just enough structure to get you “organized enough” without imposing so much structure that managing the solution becomes a task in and of itself.

“Avoiding the futility of time management” is precisely why the LATER section in Chandler does not offer more granularity. It was intentionally missing options for designating more granular sub-sections like Tomorrow, Next Week, in 2 Weeks. You can always assign alarms to items so that they automatically pop back into NOW on a particular date. But unless you have a very specific date in mind, the idea is that really, you have no idea when you’re going around to thinking about this again.

On the other hand, we have seen that users quickly accumulated so much stuff in LATER that they begin to see the LATER section as a black hole. If you want to forget about something, put it in LATER.

In Part 2 of this post, I will get go into more detail about how we might reconcile these two opposing forces in the user experience.

Of course both Jobs and Schiller know that there are times when you listen to users and times you better not. And the interesting thing is, even when developers don’t listen, they might do it for the best of their users. But how is that?

By all means developers need to follow their vision without asking anybody. They need to think out of the box and innovate. How else could they surprise and ultimately delight?

One of the main responsibilities of a developer is to keep guard over the gestalt of a program. It is all too easy to let your application burst into a universe of hardly connected little features. We have all seen it happen. But it is equally easy to ignore your customers’ needs and to embark on a journey where nobody is following you.

It is not about listening or not, it is about what to do with all the things you have learned from listening. And that is integration. The best feature is worth nothing when not integrated properly. When we read a feature request, we don’t think about doing it or not doing it. After all, if software development is not about satisfying users, then what is it? We are thinking about how we could nicely integrate it with the rest of the application without diluting its identity.

Of course, as an open project, we’ve sort of given up the element of surprise.

One of the project goals has been to experiment with involving users, developers, and other interested parties throughout the design process, making design decisions in conversations on public mailing lists. During that process it can be tempting to use “what the user has asked for” as an objective criteria for making decisions. The quote above does a nice job articulating that doing so can be dangerous for the integrity of a design, without writing off the importance of paying attention to what users are saying.

Mimi did a writeup on OSAF’s open design process last summer in preparation for a presentation she did with Ted Leung at OSCON. She goes into some detail describing how we manage conversations and make design decisions in a way that tries to preserve both the “gestalt” of the design as well as the continued interest of developers who might be pursing individual passions and concerns. Getting this process right continues to be one of the more interesting challenges of the project.