Prototypes for my event scheduler project

I’ve written a lot about prototypes since starting my event scheduler project, but I didn’t go in deep about why I was doing it, so here is it. In short, there are many unknowns in my project, both technical and product-wise, and I don’t want to go too far in a direction without knowing if it will work since my time is limited. Problems can still crop up but a few good prototypes about the harder parts will give me a good idea of what to watch out for.

ProblemsBeforeProduction

This concept of prototyping is taken from Extreme Programming (XP) practices and they call it a Spike. It is meant to be a technical exploration of a concept to reduce technical risk, which is exactly what I’m looking for.

In my case, I’m at ease with building web applications in ASP.NET MVC with jQuery so I don’t need to explore further on that front. Given that, there are two big areas that I’m aware of and that I want to explore:

Real-time updates
Since the software will be used to adjust schedules in real-time, I’ll need to investigate the best way to show modifications directly on the schedule without refreshing the whole page. This is necessary for a good user experience when multiple users will be working on the same schedule.

I probably won’t code support for multiple users right away, but I want to learn a bit more about what’s involved in managing real-time and what are the impact on the client-side code so I can at least consider it in my design.

SignalR is pretty much the default for ASP.NET MVC projects so I’ll probably go with this My experience last week when I built my database made me wary about going against the logical choice for a framework if I want to maximize my time.

Interacting with sessions
Interacting with the sessions of an event is a major part of the application, so I wanted to prototype the UI for this with as little code as possible. The point for this prototype is to validate if the ideas that I had while working on my mockup makes sense and can be implemented. Also, given that the application is meant to be used while the event is going on, it needs to be easy to use on a tablet. I already spoke about this prototype last week since I started by building a basic data model so I had data to interact with. I completed it this week, integrating the following elements of the UI :

  • Showing a list of sessions from the database.
  • When clicking on a session, a menu with options to move the session 15 minutes later or earlier is displayed.
  • The list of sessions for the room can be scrolled to show the full duration of the day and expanded/collapsed.

EventSchedulingPrototype1

I’m glad to say that it worked very well on my desktop and on my Nexus 7. I now feel a lot more confident about going forward with this for real since this test was successful. Still, I already have a few things I know to watch out for:

  • When a date is created in JavaScript, this date is in the current timezone of the browser, which is wrong for or the purpose of event scheduling. The time displayed as the start and end time of a session should be the same regardless of the location of the user editing or viewing the schedule. I’ll have to be really careful about that one, managing times correctly in JavaScript is not that obvious.
  • I used a few dirty shortcut in the prototype to move sessions, calculating the new position in the timeline from the existing position in CSS. This gets the data as a string and not as an integer, so I had to use parseInt in a few places to convert the position in string back to an integer. The final version will have something better but it’s a good reminder to always be careful about data types in JavaScript, it won’t always cast values as expected.

I also need to be careful about setting expectations for the project: it may looks like I made a lot of progress, but there is a ton of work left to do to make this ready for production. Prototypes and real, robust applications are a world apart: this version doesn’t even save modifications!

This test also made me realize that I should add one last prototype to my list: testing JavaScript frameworks. Since I need to update a few places on the page with the same information, I want to take a look at what’s available for two-way data binding. On the other hand, I don’t want to spend a month just on evaluating JavaScript frameworks since there is a ton of them available. I’ll probably just get a list of the most popular ones and test only those.

Next thing up is to do a very small prototype of refreshing data on the page with SignalR using the data I already have from my previous prototype. Anything I should watch out for?

Sign up now to get my newest articles about making applications and my ongoing side project delivered straight to your inbox.

Starting the prototype : building the database

This week, I started working on a prototype of the UI for my event scheduler software to test if it makes sense on a tablet and on a desktop. Since this is a prototype, I’m not putting any effort in the architecture, error handling or on tricky edge cases and business logic for now. What I’m testing out exactly is :

  • Displaying an expanded and a collapsed list of sessions.
  • Showing an action menu to move the time of the session forward and backward (without saving it for now).
  • Navigating in the timeline to see the whole day.

I’m a beginner with the Entity Framework (EF), which is the object-relational mapping tool in ASP.NET: I never had to use a database in my projects since all the data was from web services. Still, I figured I could start the prototype by building a small data model, and use the scaffolding tool in Visual Studio to generate views. This way, I would have an almost free way to create and modify the data for sessions in my test. Also, this knowledge will come in handy later when I build the real thing. This was going to be a breeze…right?

Here is what I was aiming to do as seen in EF. In my model, I’m including only the event itself and sessions (talks) for the event. I’m supposing everything will be in the same room and on the same day for now. Even the event was not really needed, but I wanted to see how relations worked.
first database side project
Since I learned to work with databases the old school way by first building the database and then connecting to it with my application, I decided that I would create my database first and then generate the model classes from that database with Entity Framework. It seemed the most logical thing to do since I know exactly how I want things to be stored in the database. After a while though, I felt like I was going against the logical flow of things for EF by going database-first:

  • First, I’m used to having columns names and table names in lower case in my database, and objects names in CamelCase in the application, but EF uses the same names for both. Even when I renamed thing as I wanted them in the mapping, EF keep using the wrong case in SQL queries, so I couldn’t access any data.
  • Second, while Event and Session are great names to represent the concepts of an event to plan and of the sessions (talks) for the event, they are really dumb name to use in C# code. Those class names are already used in the .NET framework used to represent an event (handler) and a browser session. If I keep those names for my classes, I’ll have to use namespaces all the time which is a pain. And as seen with the first point, just renaming the classes and keeping this name in the database wouldn’t work either.
  • Third, EF plurializes everything by default, while I’m used to singular table names in my database. I found out about this when I tried to rename my tables SessionInfo and EventInfo in a last-ditch effort to solve the problem above: EF would plurizalize the table names to SessionInfoes and EventInfoes, messing the SQL queries to the database (again).

All those problems keep breaking the project, stopping my progress. Those are solvable for sure, but there is no point to putting up with that crap since there is a better way to do things. So, I decided to cut my looses, generate my database from my model classes and stop caring about the exact structure of the database for now.

As a bonus, going code-first doesn’t required messing with the designer as much: I can just use annotations on my model classes when I want to do something in particular, for example to specify which table names and column name to use. It’s also easier to manage in source control since the code, which is now the reference for the design of the database, can easily be checked in.
Class Diagram
Of course, this worked like a charm: I just created my classes from the generated code I already had from my previous tests, generated a database and scaffolding and everything worked on the first try. That will teach my to try and go against the standard for a framework…

Moving to code-first was not enough to fix my namespace problem of course, so I also renamed my classes ScheduledEvent and ScheduledSession. This name is even better than my first choice: when I’ll add features to publish schedules, I’ll probably need a pair of classes such as LiveEvent/LiveSession or PublishedEvent/PublishedSession anyway.

In summary, this part of the project didn’t go according to the plan to say the least. I now have a good headstart on how the model with work and on how to use Entity Framework so it was a good thing, but I didn’t want to spend this much time thinking about the model at this point just for a prototype. It’s not unexpected to have this kind of setback, there are still a lot of unknowns and there are sure to be more technical surprises lying around the corner.

My software side project : an event scheduler

Last week, I spoke about starting my new side project and why I wanted to do it. But now, it’s time to define what I’ll be doing so you can follow along. I’ve toyed with many concepts over the last year, but most of them were pretty bad or would have taken too long to make. But one idea that would always stand out is making an event scheduler for conferences. The seed for this idea was planted by an heartfelt post on Amy Hoy’s blog about how most software to schedule events sucks which you can find at https://unicornfree.com/2014/fuck-innovation-take-2-the-obvious-fucking-fuck-fuckers. I’ll be shamelessly grabbing a few ideas from that post with the higher aim of making a good piece of software.

I’m still a bit unsure about making a product for which I’m not in the target market. On the other hand, managing schedules is a problem domain I know very well so I’m not straying too far from things I know. I’m hopeful I’ll be able to do something interesting and this idea can stay small enough as to be doable for a side project. I also took a quick look at my competitors: most of the products that include event scheduling seems to be huge integrated solutions that manages everything for the speaker lineup to the ticketing. I want to do only scheduling and do it well for smaller events, a market I feel is under-served right now.

ScheduleAllTheThings

The minimum viable product in that case would only have the ability for conference organizers to create their schedule and modify it easily on a laptop or a tablet. That way, the organizers can easily adjust the schedule on the fly as needed when things runs late or get cancelled. Pretty soon though, I want to add the ability to publish schedules to the public so attendees can see the latest version of the schedule on their own device. While this is not yet available, a workaround for organizers needing to show the updated schedule could be to display it on a large screen for attendees.

My usual process to create a new product beside some doodling that nobody can understand is to create a few mockups of how I’d like things to look like. I’m not a designer, so it’s mostly to have an idea of where things will be so I can see the UI for real and validate that it makes sense.

I work with GIMP, copy-pasting controls I make in Firebug by modifying existing web applications and controls. I like to use GIMP since it has layers and I have a decent handle on their drawing tools so I can do small modifications to colors, add more text and duplicate controls. Here is the first mockup I’ll be working from, which shows how the sessions with be displayed for each room in a day. I decided to go with this first since it’s the heart of the application and so needs to be easy to use.

CalendrierVersion2

When an event and a day is selected, I’ll show a collapsed view of all the sessions that occurs in a single room for the event. Sessions that are in green are not overlapping with anything and are working just fine, but sessions that are in red currently have overlaps with other sessions in the same room that needs to be adjusted. When a room is expanded, each session is shown on it’s own line. That way, all sessions will be fully visible even if some are in conflict to make it easier to adjust the schedule. In both the collapsed and the expanded view, the organizer can click on a session to show a quick edit menu and adjust the session on the fly, or open a popup with more details on the selected session (not shown in this mockup).

My next step at this point will be to prototype this to see how sessions will be really displayed. Since this is such a big part of the application, I want to explore it a bit to make sure it is easy to use on computers and tablets before committing to a decision on the design or on the architecture. Other parts of the application will be more straightforward so I’ll be thinking about it a bit more before throwing myself into the code, but most of the big unknowns are about the scheduling.