phpMyAdmin working!

Yesterday we got phpMyAdmin to work on the GNG webserver. We are very happy about this as it makes it a lot easier to maintain the database. The database is now up and running on the GNG webserver and the backend is working fine on their site too.

We also got the security part to work so you have to enter a username and password to get access to the backend. This had to be done in order to make sure that only the GNG staff will be able to gain access.

Today we have tested the player in different browsers; Internet Explorer, FireFox, Mozilla, Netscape, Opera and Safari. The player had some scrollbars in Safari as mentioned in a comment of an earlier post. These have now been removed so the player looks the same in all browsers. Unfortunately Netscape opens popups in tabs and not in a new window. This is hardcoded into the browser and there is nothing we can do about it. It's not a big problem though as the player still works as intended, just not in it's own little window.

We have also started working on some new components. The first one is a "tell a friend" component where people can enter an e-mail address and a link will be sent to it. This shouldn't be too hard to do as PHP has an easy-to-use e-mail component.

We might also start on a component that makes statistics about what people are searching for. This component will index all the words entered in the search box and count how many times people search for it. This way it's easy to tell what people are actually looking for and upload more of it.

Last but not least we are also discussing an alternative design with a more guided interface. The database and backend will be the same and so will most of the code but the design and flowchart will be much different. We will post more about this at a later time.

Search engine

Lately we've started working on the database, which is also why we haven't been posting that much on the blog. We're sorry about that, but here is a little update.

We need to create a search engine which is able to search for content in the database. Therefore we've created a database where the content has been inserted manually so we could do some testing and it seems to work as it is now.

The search engine is currently working this way:
When you add the content (videos, background reading or purchase) to the database, you have to do two things in order to let the search engine find the content.

• Choose a category and location for the content
• Assign some keywords for the content

This way the user has an opportunity of searching either by the category and/or location or by keywords.

The media library now has a working search engine, but we need to get a couple of more videos and other content stored in the database just to make sure that it all work as it suppose to do.

At this moment we've started building the backend, and the design for this turned out this way.

The database and backend, part 2

We are now quite satisfied with the design. Some changes might happen later on but right now we are sticking to the Test.

Tomorrow we will start out with some flow-charts and some database planning. We will plan how the entire backend will be build.

We also have to see if we can install phpMyAdmin on the GNG webserver. This tool is quite important when we have to build the database. If we can't get it to work we might have to build the database on another server, export it and import it to the GNG server. Problem with this solution is that it will be quite hard to correct errors in the database at a later time. The database could also be hosted on another server but that would cost more.

It also seems like the host only supports PHP for active scripting. We haven't worked as much with PHP as with ASP but they are much the same so we probably won't have too many problems.

Functional prototype

After these couple of days with both placement and visual prototypes, the time has come to create a more functional prototype of the GNG Media Player. This prototype contains the elements we've been working on the latest couple of days, such as the expandable descriptions.

This functional prototype can be found here by the name of "Test".

We've presented the functional prototype for David from GNG and we've got his acceptance to carry on our work with the prototype. Therefore we will continue our work with this prototype and soon we will begin the database part for the player.

Visual prototypes

Del Prado is doing quite a job these days with an old version 2 of Photoshop. We've gone through several more detailed prototypes based on placement prototype 4. The progress can be seen below:

Prototype 1
Prototype 2
Prototype 3
Prototype 4
Prototype 5
Prototype 5b
Prototype 5c

This gives a good idea of where we're heading. Michael has been working a bit with the design of the player. This was quite a challenge as the player component has a million different elements with a billion different layers that are linked to each other in different ways. It definitely wasn't easy to figure out how it worked but the player looks as intended now and fits Kenneths design.

The search result list is supposed to have expandable descriptions. I've been working on it today using JavaScript and it works quite well. It doesn't really have any design yet but it works.

Placement prototypes

Lately we've been working on some placement prototypes. These are programmed without a lot of graphics and are made to see how placing elements in different locations works. We have 4 elements - the GNG logo, a search box, a box for search results and a box for the video player. We've tried placing them in different places to see what works the best. The prototypes can be seen here.

At first we liked prototype 1 the most. It seemed like a good way to sort the results in 3 columns but it also wasted a lot of space for the search function. The second problem was that we've decided to limit the size of the window to 720x550 pixels in order to enable users with a 800x600 screen resolution to use the player. The search window then becomes very small and hard to find your way in. Since there won't be a lot of background reading and purchase links we decided to let this prototype go. It simply wasted too much space that could be used a lot more efficiently.

Prototypes 2 and 3 are much like each other. The biggest problem is that they give the impression of being a mess. All controls are scattered too much and the search function takes up too much space at the top of the window. Of course the search function is important but we want the video box to be the most dominating.

Right now we are working more with prototype 4. It is a bit ordinary but also the most effective way to use the space we have in the window. Actually we are working on prototype 5 right now which is a slightly different version of prototype 4.

These prototypes have been made to find the right locations for the elements. Prototype 5 will be a more extensive graphical prototype and will be posted soon.

The database and backend

We've had a lot of discussion this week about how to structure the database. We have 3 different types of items to put in the database; documentaries, background reading and things to be purchased. All of them will be based on links to external data. We have decided to treat all of these in the same way in the database. When you do a search the search engine will search through all kinds of items, find the ones that match the keywords and display them according to what type they are.

This seems the best way to do it as:

1. There is no need to build a huge relational system where administrators can relate the different types of items to each other.
2. Administrators save time and don't have to pick relations manually every time they upload new documentaries.
3. All items can easily be administered individually.
4. Items can be removed without breaking relations in the database.

As we have decided to treat all types the same way we have chosen the data fields each item will have in the database:

- Id (all item must have an Id)
- Title (Caption when being listed)
- Country (The country the material is related to)
- Section (The section/topic the material is related to)
- Description (A short description of the item)
- Keywords (Keywords designated by the administrator)
- ImageURL (URL to an image when listing the item)
- TargetURL (URL to the data the item links to)

More fields can be added if necessary. "Country" and "Section" are used for structured sections where the user might not know exactly what to search for.

This is the first outline of the database. All data will be administered through a CMS(Content Management System) using forms with input boxes and dropdown menus. This should give the backend a simple and easy-to-use interface.

FLV Player: success!

Today we've built the prototype of the FLV Player. The planning worked and we now have a flexible FLV Player that can play an URL that is passed via the page the player is on. ASP can be used to paste any URL from a database.

It doesn't look like much yet but we are pretty happy it worked and we now only need to design a GNG skin for the player instead of the standard blue one we are using for testing. The prototype we have now is actually capable of playing a FLV video from another server so it would also be possible to stream all the videos from the playstream.com server the GNG already has. Wether the webserver or the streaming server will be used will be decided later.

Of course this was only the video player module of the media library we are building and there are still a lot of work to be done.

FLV Player Prototype

All necessary research has been done in order to build FLV Player Prototype tomorrow. The new Flash 8 Professional includes a new component, FLVPlayback, that is a complete FLV player template. Only thing it needs is an URL to the FLV-file it has to play. The visual template is easy to customize in order to integrate the GNG design.

In order to make the player more flexible, we will have to create a way to send FLV-files to the player dynamically. This will be done using a combination of a database, ASP and FlashVars. The reason to do this is that we want end-users to be able to add new FLV-videos without having any knowledge of Flash. This is essential to the usability of the backend.

We will then use the ASP to create a FlashVar for the player that contains the URL to the FLV-file it has to play. Instead of hardcoding a FLV URL in Flash, the FlashVar will be used. This might require a bit of ActionScripting but shouldn't be that hard to do. Explained in another way, it will work like this:

1. The user uploads an FLV-video to the server and types the URL in a text box.
2. The URL is stored in a database along with other info about the video.
3. When a visitor wants to see a video, ASP is used to build a page where we pull the correct URL from the database and put it in a FlashVar for the Flash Player.
4. The Flash Player will read the FlashVar that was created on the page and play the URL it has been given.

Not all elements will be used in the first prototype as they are not necessary to make a quick test of the system. Tomorrow we will see how the first test works out!