Click here to Skip to main content
65,938 articles
CodeProject is changing. Read more.
Articles / web

Slitastic

5.00/5 (13 votes)
13 Aug 2013CPOL18 min read 67.7K   304  
Creating a highly extensible presentation app with multi-user and device integration for tablets.

This article is an entry in our AppInnovation Contest. Articles in this sub-section are not required to be full articles so care should be taken when voting.

Slitastic Logo

In this article we will present our idea Slitastic, which targets tablets in the category education.

Introduction

Roughly one year ago the first Intel "App Innovation Contest" started. When we started out with an idea for this competition, we weren't sure how to attack the target of a touch capable UltraBook. A year passed and I think the final decision, to embrace the UltraBook with all its components, not just the touch screen or the sensors, has been proven to be the right one.

With the latest generations of UltraBooks we see other exciting technologies being included, like webcams with depth sensors. Such technologies already enable interesting projects on their own, but if they are combined with other features we are in technology-wonderland. An example would be the combination of sensors like the accelerometer, with a 3D camera like the one used for the Intel Perceptual Computing contest. The scanning capabilities go far beyond image recognition. It is now possible to actually not only do image recognition with the information from the image, but also with additional information from the environment.

In this new contest we will again be present - obviously we have a title to defend. We are not dreamers, so we know that winning will be more than hard, and in the end details will matter that are beyond our control. Nevertheless we think that our new idea is great and will eventually become an interesting app. This time our target audience is again in education, but one could also call the category productivity. Our target machine is again a tablet / UltraBook - we are making a touch focused application that will become even better when used with a keyboard. In the end we plan to create the most advanced and innovative presentation app ever written...

An overview of the application and what it does will be given in the section the idea. Additionally a description of the intended uses for the application are given visually with the teaser download above (it's a PDF document contained in the given ZIP file), or in the features section.

The approach taken to develop the application is explained in depth in the section about the implementation. There, the used coding languages are also presented, along with the benefits from our choices.

Background

For years the words slides or presentation have been clued to the program Microsoft PowerPoint. There have been other applications for the same task, but none of them reached the popularity and acceptance of the Microsoft Office application. Now with the rise of tablets and smartphones, people have found other apps to accomplish their tasks of creating aesthetic presentations.

In academia, especially in Mathematics, Physics and Computer Science, LaTeX presentations are very popular. The big advantage of using LaTeX is that everything is written in text and "compiled" later on (usually to become a PDF, but other targets are also possible). The need for having a special GUI (which might be error-prone, slow or inaccurate) is obsolete. Additionally equations from other (LaTeX) documents can be easily inserted and just look brilliant.

Finally there is also a new kind of presentation program, known to most people as Prezi. The focus here lies on images, as one can build whole presentations just around the connections that lie between images. Here, transitions and effects are really important. This kind of program goes in the direction of an original slide presentation, where reversal films have been used in combination with a carousel. Someone will tell a story and use images to show specific scenes or make some statement.

Let's have a look at the specific areas of those three programs - along with a new idea that will be presented in the next section.

Powerpoint Prezi LaTeX Slitastic

So all in all Slitastic tries to combine the advantages of these programs into one powerful touch friendly, multi-user app.

The idea

As previously stated, in the recent years people have shifted from one program for presentations to several programs. Now it seems accepted that there is no silver-bullet for creating presentations. There are many ways and a different kind of presentation might be better off with another kind of program. Also it seems to be accepted that PowerPoint is not the only presentation program.

So what is our idea? We want to create the world's most advanced and innovative presentation program. It will center around three things:

  • Being transportable, i.e. HTML will be used as markup language for a presentation.
  • Being tablet / touch friendly and allowing custom extensions like for perceptual integration.
  • Integrating other devices, like using a smartphone for controlling presentations or making collaboration as simple as possible.

In the end our app will be the creative cornerstone for building presentations. Nevertheless it is one of our design goals to put the focus on the content. Controls will be only shown where required. There will be a minimum amount of chrome. What is a really important point here is that every user interaction will not only be possible by using touch only, but also be made for touch only. Of course the mouse will also work just fine - and typing with the keyboard will be more fun as well, however, buttons and their behavior are touch-first.

Since we want to decouple everything we also decouple the user interface from the application. In the end our application will be just a simple "hub". This hub does the hard things like document or state mangement. It is also responsible for application updates, connections to online services or other devices and much more.

Features

In this section we do not want to talk about all features. We will now mainly discuss some important features of the app with one feature in more detail: the so-called SmartPointer. Let's start off with a (short) list of general features:

  • Plugins / extensions
  • Layouts and templates
  • Shapes / drawing
  • Transitions and animations
  • Math equations
  • Source-code editing
  • Scriptable program flow
  • Image effects / image-flow
  • Hub / cloud-based
  • Touch-first with pen integration
  • smartphone support
  • Audio and video support
  • Streaming capabilities

Since we are in the browser we have direct scripting support by JavaScript alone. The whole application will have a common API, which makes it very scriptable. This allows advanced users to create whole presentations in just seconds by applying old scripts with different variables.

Created presentations can be exported (and re-imported) as HTML, which makes editing the presentation without having the program installed very easy. This is actually a very LaTeX like way, with the distinction that the only program required to show the presentation is a webbrowser (i.e. it will run everywhere).

A very important point is the plugins / extensions feature. The whole application will be very extension focused. In fact nearly everything will be programmed as extension - only a few core concepts will be directly implemented. We will discuss this in detail in the next section.

For now we want to go into details about the SmartPointer feature, which makes use of an existing smartphone. The idea is the following: Why does one have to buy a special device just to have a laser pointer with control capabilities (forward, backward)? Why not just use the smartphone for that? Of course there is no laser pointer integrated in a smartphone, but why do we need such a device? A smartphone has several sensors and there are several advantages of not using a laser pointer:

  • You know exactly how much battery is left
  • You cannot attack the audience with the laser beam
  • The smartpointer could be smoothed, which reduces shaking
  • You don't have to point in the direction of the screen
  • More advanced options are also possible

The mockup UI we present for the SmartPointer app looks like the following:

SmartPointer Design

We will not release the SmartPointer app in the local app stores, but as a web app (i.e. we will make a webpage). There are several reasons for that - and I think they are quite obvious. On the one hand we do not have to package our web app as a native program, on the other hand we are getting around the various fees and most notable we are also getting around the sometimes very slow acceptance step. This also ensures that our application is always up-to-date. Finally the distribution process is much faster than having to submit the app to all the different app stores.

So how will the SmartPointer actually work? Well that is quite simple...

smartphone rotate

We are binding the orientation sensor of a smartphone to screen coordinates. That means that between (0, height) for Y on the screen we actually have respectively (45°, -45°) for beta on the smartphone. Additionally between (0, width) for X on the screen we have respectively (-45°, 45°) for alpha on the smartphone. Right now there is no obvious usage for gamma, but the user could activate it for special purposes. One purpose could be that the presentation rotates after gamma has reached a certain threshold.

With the ability to set the actual shown marker in different sizes and colors, we think that the SmartPointer is actually much superior to the common laser pointer. Since nearly everyone has a smartphone already, there is also no need for an additional device. Right now the SmartPointer will be only designed for Slitastic, even though a much more general implementation could be possible as well.

But we do not only integrate the smartphone as a suitable pointing device. Additionally we are integrating multi-user support from the start. The whole application will be designed with multi-user support in mind.

Another factor is the usage of the local sensors. If sensors are available then the orientation will be used to enhance the experience of creating content. Furthermore if a depth camera is available we will integrate basic gestures like swiping or thumbs up for controlling presentations. A rich set of voice controls will be available as well.

Finally the support for an external stylus will be present as well. We will allow the user to make drawings directly on slides - enabling a fantastic mixture of analog and digital typesetting.

Architecture

The architecture of the system is focused around the so called Document Hub. This program is a very simple WPF application. It will enable the web application to access the file system, keeping track of the state without any localstorage limitation and accessing complex abilities like the perceptual computing SDK or the sensors without being dependent on the web browser.

The document hub does not only serve the content (User Interface), but it is also responsible for updating the application as well as connecting the online services. These online services let users connect other devices to the local application. Of course there is some security system built into the whole application, which will prevent unauthorized access from any other device.

Slitastic architecture

Hence we have two possible end-points in this application:

  1. The local computer with browsers (out-of-the-box the application will work with that).
  2. Other devices with browsers (additional authorization will be required to allow these connections).

Let's have a look at the various layers that will be built up for this application. From the perspective of the document hub we will to wire up a lot of different functionality aspects.

Slitastic layers

The main points here are:

  • Slitastic will manage documents in its own format.
  • Files like the views, images, scripts or other resource files will be embedded.
  • The whole HTTP, Control and Views concept will be handled by a lightweight MVC architecture.
  • A very crucial point is the extensions module. Extensions will most probably be served as NuGet packages from a Slitastic package server.

All online services will most probably run on Windows Azure. This will give us flexiblity and robustness. Additionally it makes it possible to scale the dimension of the service according to the demand.

Finally a big feature will be the usage of the SmartPointer. As already explained the SmartPointer enables smartphone to not only control the presentation, but also show certain things like with a laser pointer. Having a SmartPointer will not be required, but present a nifty feature, that will most probably be used a lot.

Slitastic SmartPointer abilities

The laser pointer is closely related to reading out the orientation sensor of the smartphone. Therefore we need to detect rotations. Additionally a button will be needed to activate the laser pointer. If the button is not pressed, no dot will be shown on the screen.

The data received from the orientation sensor will be smoothed. This will prevent small numerical errors to propagate and will have the nice effect of reducing the visibility of shaky hands.

The implementation

As implementation languages we make some natural choices. The hub application will be programmed with C#. We will use some features of the .NET framework and some external libraries like AngleSharp (for keeping track of the HTML DOM, plus features like importing, exporting and more) or Nancy (for providing a very lightweight MVC architecture to serve the content). The views will be written with the Razor language, which is perfect for extending HTML with C# code. SignalR will be used to manage the real-time communication.

The GUI uses HTML5, CSS3 and JavaScript. We will write the whole JavaScript with TypeScript, since this will usually result in a dramatic reduction in run-time bugs. Less bugs means less testing and debugging required, which will eventually result in a faster development process. The stylesheets will be coded with LESS, which will make it as flexible as possible.

Tools and material

Our tooling stack includes some of the most well-known tools available on the market.

  • Visual Studio 2012
  • Web Essentials 2012
  • Emmet
  • git
  • Sublime Text 2
  • LINQpad
  • SparkleShare
  • Blend
  • GIMP

While Visual Studio will be used for the whole project management including coding C#, TypeScript and LESS, Web Essential's job is to create CSS and JavaScript files on the fly. Additionally Web Essentials give us some other nice features for web development. Here Emmet also really shines. It enables us to write HTML in a very short and simple way.

For our VCS we use git. We will either do it as usual and use TFS, which works great with git, or we will use a private repository server in form of a Raspberry Pi. Other files will be synchronized by using SparkleShare, which is designed to work on Linux with Mono installed. Finally some plain JavaScript, CSS or HTML coding will be done by using Sublime Text 2.

For writing short evaluations or testing small code snippets the tool LINQpad will be used. This tool is great for quick prototyping without having to open whole projects. Furthermore MSIL and very nice result views will be displayed as outcome.

Designing the application will be done mostly by hand. For some prototyping the tool Blend will be used. Images will be created and modified with the free tool GIMP.

Dependencies

The whole application will require .NET 4.5. The reason for this is mostly given by the requirement of .NET 4.5 for the best async / await support. Otherwise .NET 4 would have been sufficient as well. Since we are also using tools like Nancy, Razor or SignalR we are also dependent on the ASP.NET core library.

All our dependencies should also work with Mono. Even though XAML / WPF is not supported on other platforms than Windows, porting the application should be easily possible. The document hub is quite simple and could therefore be rewritten for other GUIs very easily. Right now we do not have any plans to make a platform-independent version of Slitastic, however, it would be much easier than with previous projects.

So what kind of obvious dependencies beyond .NET 4.5 do we have?

  • A TypeScript compiler
  • A LESS compiler
  • Razor v2
  • SignalR
  • JSON.NET
  • AngleSharp v0.3 or higher
  • Nancy
  • NuGet client
  • jQuery v1.9.1
  • Twitter Bootstrap
  • Font Awesome

These dependencies can also be visualized in various categories. Let's have a look at a block visualization.

Slitastic Dependencies

We will not use Knockout (or AngularJS or similar) for doing MVVM on the client. All our model binding will go over our JavaScript API, which will be much more dynamic and service centered. Therefore we will use a custom solution here, which will be superior to these other frameworks (superior in this special case of course - not in general).

Non-trivial code

Will be discussed in Round 2.

Problems and solutions

Will be discussed in Round 2.

The extension system

Will be discussed in Round 2.

End-user experience

This section is at the moment a little bit of guess-work. The app has not been written yet, which means that any assumption how customers will interact with it or use it can be totally off the road. Nevertheless what do we think - how will users interact with Slitastic?

In our opinion most users will certainly go on and create content mostly with keyboard and mouse / the touchpad. Even though we think that most users will still interact with the app by keyboard and mouse we are (as one should) designing for the extremes: touch-first has priority! The user will start the Slitastic app, which will open a webbrowser with the last open document(s). If no document has been created yet only the hub is shown. Here the user can simply click on add document, which will open a new document in the user's standard browser.

Now most of the time the user will edit or add content to the presentation. For doing so he will either click somewhere to enter text, or use one of the more advanced options like the shapes extensions. Here the user can drag and drop a variaty of shapes. Added shapes can be modified at will. They can be re-colored, re-sized or just transformed.

Some users might want to share their presentation with others. All they need to do is press the share button and enter the username of the person they want to share the presentation with. They can select if they want to enable modifications or not (readonly-mode). This will enable other users to open a document just by typing in the username of the creator and selecting the specific document (there might be more documents if the creator has shared more documents with this person).

Now the collaboration is in real-time. If one collaborator lost the connection, then changes will be buffered. This system will actually be quite powerful, since it allows real-time collaboration, but it does not rely on it. If the original creator is offline the online service will do the buffering and inform the creator later on.

Finally its presentation time! The creator has probably already set up his SmartPointer (which is a matter of two minutes - just go to the SmartPointer webpage and enter username and password for the Slitastic account; there you go!), which means the SmartPointer detects that a presentation by the user is running. This means the webpage can be used without any more configuration.

What is worth noting here: We try to make everything as simple as possible. We want to include very advanced features for power-users (like scripting or editing the source directly), but usually they are not present. The user just sees the absolute minimum: a minimum of chrome, a minimum of settings, etc. - the idea is that everything will just work fine with a minimum amount of configuration. If users want to be more specific they can, but this is all optional.

The rest will be discussed in Round 2.

Points of Interest

Writing my own presentation app is one of my dreams since a long time. We think the architecture is pretty interesting, yet it is already in use by some very known programs. The innovation here comes with the integration of other devices (like the smartphone) and the multi-user / touch first paradigm, as well as using HTML5 for the presentations and the GUI. The final application will certainly not be as feature-rich as PowerPoint, but this is what the extension system is about. Our plan is to provide a system that easily allows us to enable further extensions without changing any of the main program.

It is therefore required to follow the dogfooding principle by programming some of the most important parts of the program as extensions, like always going over our own JavaScript API, which will eventually trigger the C# API. Even though this seems more complicated at first, it has several advantages. First of all we see directly what API calls are missing, second we experience how hard it is to program an extension for Slitastic. It should not be complicated at all! If it feels complicated then something is definitely wrong.

We won't reach the clarity of LaTeX, since HTML does not provide such a nice typesetting at the moment. Nevertheless we want to make equations look about as good as in LaTeX. In the end it will be pretty interesting what will come out. Personally, I have high expectations for this app. How are you feeling?

History

  • v1.0.0 | Initial Release | 12.08.2013
  • v1.1.0 | Added poster for download | 14.08.2013

License

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)