Belize is thriving in tourism. Lots of tourists go there on holidays to enjoy its beautiful beaches and a wide range of restaurants. The government of Belize is trying to enrich tourists' experience in finding their favorite restaurants in the country more effectively. To accomplish that, a new project titled Bestaurants has been proposed to design a website to feature the best restaurants in Belize. For that, they asked for the website to be able to run on both desktop browsers and mobile devices.

The website will contain a map that shows the city of Belize and the restaurants with key icons based on the restaurant type. For example, a café will be shown as a coffee mug and a restaurant will be displayed as a fork and knife. Tourists should be able to search for restaurants by name, category, or rating. The results should show the ratings, reviews, and pictures of that restaurant if available. The user will only be able to upload photos and write reviews. When the user opens the website from his mobile phone or a tablet, they should get the exact same functionalities that are available in the web version. Finally, the website will identify and show the user location on the map using the Global Positioning System (GPS) receiver on the device. The user can then highlight all restaurants near them by clicking on a button.

Before we start the development, we need to get a picture of what the website would look like after it is completed. That is what is called the Interface Design; we can do it on a piece of paper or using sophisticated software such as Microsoft Visio. What is important is to capture what the website should look like.

Let's start designing our canvas; we will start with the most important element of the website: the map. I know that there will be a map because the project statement says:

The map will display the restaurants, and the user will be interacting with it. The map should be the biggest object on the site as it will be the focus point for the user. The map will need zoom functionality, so we will add a small slider to the top to help the user zoom in or zoom out. Moreover, the user will require a legend to show the key objects on the map; so we will reserve a space for that as well. Reserving 25 percent of the left side of the website will suffice for the legend. The following figure illustrates what the application page design will look like. Remember that the design can be changed as we progress through the chapters.

The website looks simple and zen, but unfortunately, we cannot keep it this simple. We need to add more elements to the design. Read the following quote from the project statement:

This quote implies that we should have a search box and probably a drop-down list for the category and rating. The bottom line is that there will be some input controls that the user will interact with; so we need to reserve a space for it. Let's reserve the upper 10 percent of the web page for input controls. We also need some space to display the search result where we can display the restaurant name, rating, reviews, and photos. For this, we can use the left area, below the legend. The new Interface Design is illustrated in the following figure:

As the user searches and interacts with the map, it will be nice to display some status and loading messages for them. Let's save the bottom five percent of the page for status messages.

Of course, this design is not written on stone, so you might want to move things around as you progress through the book. Take a look at our initial Interface Design:

Before rushing in to the developing process, it is always good practice to create the architecture of your components. This helps show how the entire solution is tied together. The architecture describes the software, hardware components, the relations between them and assess in viewing the solution as a whole. With the architecture, the developer can see the big picture before diving into the details of implementation, which may save them a lot of time and make them consider exterior elements. You can read more about system architecture at:

http://www.esri.com/library/whitepapers/pdfs/sysdesig.pdf

The first part of the architecture is to make a decision on what programming language is suitable for the web application. This can only be determined by reading the requirements. Let's take a look at the following quote from the project statement:

The best option to make a web application able to run on both mobile and desktop is to use a language that will run on both. ArcGIS provides APIs for Silverlight, Flex, and JavaScript. Silverlight and Flex are good and simple programming languages and provide rich interface and logic; however, they both require browser plugins to run, and no smart phone supports it, so they are out of the question. This leaves us with the ArcGIS JavaScript API to develop our web application. The reason we chose JavaScript is that this scripting language is open standard and can run in modern browsers including mobile devices. JavaScript is a client-side scripting language, which means all the code executes on the client. Keep that in mind while we design the architecture. Note that JavaScript API is a volatile SDK and a continually evolving API. Esri continually releases updates for this library at least twice a year, adding new functionally in each update. It is crucial to mind which version you are developing on, use one, stick to it, and upgrade as you see new functionalities that you would like to use. Fortunately, this API can work with services shared and published on ArcGIS Online, which makes it a really good choice.

Now that we have selected our programming language, there are four main components we can look at in our Bestaurants project. The components are listed as follows:

Let's explain this design, from the moment a user opens the web application up until the moment they are served the map, in the following steps:

In our case, the web server, ArcGIS for Server and the database components are located on a single machine named ARCGISMACHINE. You can choose to put each component in a separate server, which is a good practice for scaling each component independently later.