Chapter 2 nearing completion!

It has been over a month since my last update for Path to 2265. Since then, there have been some big and exciting changes!

SearchEngine upgrades

I’ve once again made large improvements in the search department. Natural ordering, more meaningful weighting, complete and proper tag finding, and basic filtering are now present! Numerous pages benefit from the improvements, but the site search itself gains the most by finally getting a basic filtering mechanism that allows you to view search results of a specific category!


Dynamic content

In order to promote better reusability of data, I’m starting to offload various parts of the website to the database. Since January, the UESPA/ECS ship registries and the reactor pages now use the database to grab data. Another advantage to this approach is that it allows cross-referencing to happen for certain items in the future – for example to reduce data duplication, I can now stop writing the unit listing for ship classes twice (once in the ship database and again in the registry database) by allowing both sources to reference one place.

New font

A new font is being used for the website’s header (navigation bar) and side menu on mobile devices. It’s called “Airborne” and is the font used on Federation ship hull marking.

Status of Chapter 2

Chapter 2 is about 75% complete as of now. Now under the chapter name “Expansion towards a United Earth”, the report focuses on early freighter development under the Earth Cargo Service, advances in explorers by UESPA, the Earth-Kzin Wars (from Star Trek: The Animated Series), and Warp drive limitations being experienced by Earth in the 2100s. Ships currently added, being added, or due to be added include Y-500-class freighter, Polaris-class diplomatic escort, Emmette-class surveyor, J-class freighter, Patterson-class battleship, Declaration-class demonstrator, DY-732-class multi-mission ship and RT-class explorer.


The first new ship is Y-500, a conjectural design of a canon freighter class mentioned in Star Trek: Enterprise. I’ve assumed relation with the DY-500s, so I quickly designed the ship as a cargo-only variant. The class’s specifications are currently being drawn up, and thus has not been included in chapter 2 yet.



Previously completed personal design. Designed to be fast and reliable diplomatic couriers for Earth that play a role in early diplomatic successes and trade deals. Registry starts at UESPA-20.



Emmette is a canon ship seen briefly in the Star Trek: Enterprise intro, but suffers with very little details available about the design and the ship’s history. Specs and missions are completed but are purely conjectural. Registry starts at UESPA-27.



A well-known and documented canon freighter from Star Trek: Enterprise. Registry starts at UESPA-47 for UESPA service and a large number of ECS registries have been created. The only true canon ship of the class is the Mayweather family’s ECS Horizon. I’ve placed the canon named but not seen ECS Constellation as a member of the class.



This is my latest developed design, based on an old UESPA-9 (SS Voyager) concept I drew up around early September 2017. It is supposed to be Earth’s first battleship and an instrument to help describe the Earth-Kzin Wars. They are heavily armed for the period, power hungry, and unwieldy. Registry starts at UESPA-57.



Another canon design with conjectural history. The only thing we know is that XCV-330 (SS Enterprise) is a class member. Given their obvious difference compared to other early Earth designs, I’ve written them to be a series of demonstrators for a new type of Warp field generation that ultimately fails to gain adoption. Registry starts at XCV-300.



Exists in canon as a class name only. The original design was made by Kris Trigwell – I redrew the ship with modifications for Path to 2265. Like the preceding DY-500-class, I designated the class as a multi-mission ship. I even included a mention of the [N] variant! Currently the design’s specifications are complete and it is present in chapter 2, but it still lacks a description on its ship article page. Registry starts at UESPA-68.



Another conjectural design of an unseen canon ship, this time the RT-2203-class from Star Trek: The Next Generation! I designed the ship to be on the same lineage as the Polaris and Patterson-class, with design inspirations coming from Masao Okazaki’s Bison-class. Registry starts at UESPA-82.


Addition of organisations

This is a new database section for various organisations and companies in the Star Trek universe. At the time of writing this, four organisations are currently available for reading about; Cochrane Institute of Alpha Centauri (non-canon), Earth Cargo Authority (canon), United Starship Agency (fanon by me), and Yoyodyne Propulsion Systems (canon).

Large ship renders

Due to the rising prominence of higher resolution displays, I am making it a priority to offer large renders of ships to cope with the larger and better displays becoming more and more available. Catering for up to 1080p might not be enough anymore, so I have started to redraw some of ships that are not original from to match the 2500px+ width of my personal design renders. Four examples exist at the moment; above with Declaration and DY-732, and below with DY-500 and DY-950:

DY-500-class render (canon design):

DY-950-class render (original design by Kris Trigwell – modified by me):

Upcoming additions

Before chapter 2 can be deemed complete, a few supporting database articles need to be completed to support the narrative – namely Yoyodyne II and Cochrane III reactors and the beginnings of the People database section (Zefram Cochrane and Henry Archer).

Once chapter 2 concludes, work towards chapter 3 will begin immediately. The chapter will focus on the early years of the United Earth government, the founding of Starfleet (as a division of the UESPA), the struggles of the Warp 5 program, and the beginnings of the NX program that leads to the development of first Warp 5-capable starship. Approximate timespan will be 2115 to 2150.

Currently planned ships are (in no particular order):

  • “Archer’s Model” demonstrator
    • Early Warp 5 program testship
    • Will be the same design as the remote-controlled model ship built by Henry and young Jonathan Archer in 2121 as seen in the pilot episode of Star Trek: Enterprise
    • Ship name to be decided
  • “BBI-993”-class explorer
    • Follow up explorer to the RT-class
    • Mentioned only on an ‘okudagram’ in Star Trek: The Next Generation episode “Up  The Long Ladder”
    • Class name to be decided
  • DY-950-class multi-mission ship
    • Second-to-last member of the DY-family of starships
    • Conjectural design already completed based off Kris Trigwell’s vision and interpretation
    • Mentioned only on an ‘okudagram’ in Star Trek: The Next Generation episode “Up  The Long Ladder”
  • Y-class freighter
    • Canon and well known freighter design
    • Seen in multiple Star Trek: Enterprise episodes
    • Written as a ship to use up previously discarded reactors
    • ECS-2801 (ECS Horizon) is a canon member of the class
    • Canon mentioned but unseen ECS North Star is written as a member of the class
  • Neptune-class surveyor
    • Canon mentioned but unseen surveyor
    • Earliest class of ship to be explicitly stated as belonging to Starfleet
    • Purportedly has the same captain’s chair as the later NX-class explorer of 2151
    • Mentioned in dialogue in Star Trek: Enterprise episode “Singularity”
  • “Warp Delta”-class destroyer
    • Well known and fan favourite early Starfleet ship
    • Frequently deployed on defence missions
    • Starfleet’s workhorse and single most numerous ship of the 2140s and 2150s
    • At least 50 ships in the class
    • Seen in multiple Star Trek: Enterprise episodes
    • Despite numerous on screen appearances, ship names and even class name remain unknown
    • “Warp Delta” is the behind the scenes nickname given by the design staff
    • Class name to be decided
  • “Sarajevo”-class transport
    • Well known Starfleet ship
    • Seen serving as a personnel transport
    • Seen in multiple Star Trek: Enterprise episodes
    • Sarajevo is a canon member of the class
    • Class name to be decided –  Sarajevo is currently the placeholder lead ship
  • NX demonstrator
    • Late Starfleet-Warp 5 program testships
    • Three known ships; NX-Alpha, NX-Beta, and NX-Delta
    • Only Alpha and Beta were seen on screen
    • Delta was only mentioned in dialogue
    • Both appearances and dialogue mentions from Star Trek: Enterprise episode “First Flight”
  • “Arctic One”-class research ship
    • Well known Earth ship
    • Seen serving as an arctic explorer and a moon-based transport
    • Seen in multiple Star Trek: Enterprise episodes
    • Arctic One is a canon member of the class
    • Class name to be decided –  Arctic One is currently the placeholder lead ship

January has been hectic

Where do I begin…

January has probably been the busiest month in my entire life. No kidding! Constant work, personal projects, assignments, and very little free time to myself. But I am happy to say I have enjoyed all of it!

Since December
Since my last life update last month, I have had two coursework results back from my Computer Graphics and Tool Development for Computer Games modules. The former was a 2D OpenGL scene demonstration where we had to sample OpenGL objects and techniques and demonstrate them – from Vector Array Objects to hierarchical modelling. The demo at the time went well, and I got 88% in the end! The latter was building a Python missile command game clone with the Pygame engine and developing a small physics simulator called “Marble Madness” with a lecturer-developed engine (PGE). I had 90% on that one. So I’m happy with my performance last term to say the least!

Computer Graphics
For the second term, this module now focuses on 3D rendering in OpenGL and 3D modelling with Autodesk 3DS Max. Things have continued to go well this term, and 3D modelling is actually more fun than I imagined! It has been useful for my group project in another module as well! The programming side is obviously interesting, but we are still in the opening weeks and have not done a lot of programming for OpenGL 3D yet.

Tool Development for Computer Games
Whilst I don’t have anything against Python, the module is a lot more interesting for me this term now that we are starting to do C# GUI programming with XAML. Whilst I have done a few WinForms projects before, WPF is something I have never touched before! The coursework looks like a nice challenge too, which is to build a game level designer for a tile-based game. We are given the game and its source code and have to build the designer based on the code ourselves!

Data Structures & Algorithms With Object Oriented Programming
This module recently had a coursework due on the 12th, which was the process scheduler assignment I talked about in a post back around late-December. Basically, we were given a public API to conform to and told to fill in the blanks in C++. My scheduler ended up being a multi-level queue with a custom algorithm that creates a cycle to prevent blocking (the act of higher priority items stopping lower priority items from being processed completely). The scheduler creates a cycle in which each level of priority (from 1 to 10) gets a certain amount of attention. Higher priorities get more attention than lower ones in the cycle, but the lowers still gets *some* attention rather than none.

Other than the coursework, this term has also taken up a slightly different theme. We are now covering different design and strategy patterns to OO programming. Whilst they certainly require a bit more thought to understand, one of the two we have learnt so far has already came in handy with my web work! The observer pattern, which states the relationship between a subject (essentially some hub) and its observers (dependencies like clients), is basically the same principle of the way I’m developing this small social network in PHP for my portfolio.

Professionalism: “Project FallingStar”
Once again, the largest and most impressive thing I am involved with at University. My team has made significant progress and whilst we are far from having a complete game, the game is looking rather beautiful already! Besides defacto leadership and physics programming, I have also undertaken tasks for 3D modelling and special effects for the game. Like the last time I wrote about this, I have some little peaks for you:

Personal projects
I have also made a fair bit of progress with personal things as well. My Star Trek fan site, Path to 2265, remains a top priority for me and many improvements in the back-office have been made. The website’s search engine programming has transformed into a mature, secure and robust platform that allows the website to provide intelligent and weighted search results, whilst also providing internal benefits by allowing pages to be more dynamic and use the website’s database more. I’ve also been working on actual front-end content as well with Chapter 2 being released within a month or so and several more ships added; Polaris has a completed database entry, DY-732 has its specs mostly ironed out, and an upcoming design is due for completion soon:

The new (but still prototype) design – UESPA battleship SS Patterson (UESPA-57)

I have also resumed limited work on my old GeckoFX-based C# browser KAubersnek. I’ve been adding a few features over the weeks and will likely continue full development when I have some time.

KAubersnek in its current state


Anyway, that’s it for now!


Secure site search

In my last update for Path to 2265, I briefly described the major improvements made to the searching capabilities of the website. Today, I’m going into detail about these changes and why they are important for security and code quality. Examples included!

How it was
The decision to add a search to the website was made fairly early on, during a time where other aspects of the website like the visual layout design were more important to me. This resulted in a crude but working search solution that you can read about here. It is a very linear search in that it just finds and returns the results sequentially in the order they were found by the SQL query. And that was fine back then, but something better is needed now!

I should mention that in November, the search feature got a little attention with the conversion from raw MySQL calls to PHP Data Objects (PDOs) with prepared statements. Whilst this was a major plus for security, the implementation was still ugly and quick.

The new concept
A search that is to be deployed on the WWW needs to be functional AND secure. It is not hard to find reports about SQL injections and other malicious acts against site searches that can be a pain in the butt to deal with. With that in mind, I decided to rebuild the search engine from the ground up with security (and good code quality) in mind. The new concept calls for class encapsulation as well as PDOs – the usage of object orientation allows for controlled access to the code querying the database by only providing a set amount of methods and required arguments to interact with said code.

How does this all benefit security?
Well, PDOs alone do not help much in terms of security. But the usage of prepared statements does by separating the variable part (in our case, the search term) of an SQL query into a method that can safely bind the variable and exclude any nasty code. Here’s a good page about SQL injections and prepared statements!

Class encapsulation also does not actually affect the SQL’s ‘secureness’ directly. But if it is used right, it can provide a reduced interface that could be used for code security purposes (as well the usual benefits of using object-orientated code). If the core code is not in a class, the code will be executed in a procedural manner where there are no barriers to what you can supply that code. But if that core code is in a class, you can then write a select few methods inside that class that can access that encapsulated code with a parameter set that can be as wide or as tight as you want. In my case, I want to tighten how the code is accessed, hence “reduced interface”. All methods that can be called only take in data that I believe is needed for operation and nothing more.

Example – class specification
This is a listing of the class members for an example I will be using to show off these concepts at the basic level. The class structure is based on Path to 2265’s engine – the major difference is the exclusion of the experimental ordered tag search (more about that in a later update) that I am still working on.

  • private $dbHandle
    • stores instance of PDO object with database connection details
  • private $statement
    • stores prepared statements
  • private $query
    • stores last-processed query string
  • public __construct()
    • class constructor
  • private cleanString($string)
    • removes special characters from any input string
    • $string – input string to ‘clean’
  • private processInput($input)
    • breaks down an input string into an array of characters for tag searching
    • $input – input string to break down
  • public createStandardSearch($class, $col, $term)
    • executes a linear search
    • $class – table in the database to search from
    • $col – column in the table to match from
    • $term – input string
  • public createTagSearch($class, $string)
    • executes a basic unordered tag-based search
    • $class – table in the database to search from
    • $string – input string
  • public countResult()
    • returns a count of results matched
  • public getResult()
    • returns result for when a single result is expected
  • public getResults()
    • returns result for when an array of results is expected

Example – implementation
I have uploaded an implementation of that class specification that works almost out of the box (you’ll need to enter your database’s details etc). As I said earlier, it is based on Path to 2265’s code for the same functionality.


Disclaimer: if there are any errors in that code, I am not liable for any damage they may cause – the code is provided for demonstrative purposes only.

An example of how you could interact with the SearchEngine class from the ‘outside’

Other possible applications this example can do
The great thing about this implementation is the fact that it can be used for things other than just ‘normal’ searching. By using the standard search feature and retrieving a single result, you effectively have the main thing you need for making a dynamic website!

So if your website has something like a database-style section (many in the case of Path to 2265), you can get rid of those countless HTML pages and have a single page instead that calls upon the SearchEngine to find and retrieve the desired page data (indicated with a unique ID through a variable in the URL) in your MySQL database and display the information accordingly.

The best example of this on Path to 2265 is the Database section: clicking on any of the ships (take as an example) takes you to the same page for all of them, expect they all have a different IDs in the URL. A provided ID on that page is fed into the search engine via a standard search call and the single result is fetched and echoed into their destined positions in the markup for you viewing pleasure. It’s great, isn’t it?

Anyway, I think that’s it for today! I hope this has been an interesting read!


Site name simplication, PHP classes, and more

So I’m gonna be shaking up how I do updates for Path to 2265 from now on. Firstly, these updates are going to be more structured because I want to make them easier to read. Secondly, I want to make it so people can either briefly look at the change list or read details depending on what they want to find out. Also I am removing any set times for posting updates since I’ve missed almost all the targets for posting them these last few months. So with out further ado, here’s we go!

Sitename simplication
I have decided to drop the “Starfleet” part of the website’s name. I believe “Path to 2265” is a more clean site name and it matches the domain name now! Plus, both sides of the “to” are ‘balanced’ with four characters each now (as long as you’re not counting spaces)!

Reimagined search engine capabilities
For a long time, the searching capability and ship report part of the website have continued to rely on the fairly crude MySQL calls demonstrated all the way back in September. By early November, I upgraded to using PHP Data Objects (PDO) for enhanced security and code quality. Now, I have moved to class encapsulation as I become more and more proficient with coding in PHP! So with this object orientated approach, the code required to connect and query the database can be contained and interacting with the “SearchEngine” object can be securely controlled by only allowing certain methods with certain argument sets to be called. The search is also now (FINALLY) a tag-based search and I am currently developing an algorithm that can weight the results of one or more SQL queries and display the most relevant results to the user! I’m thinking about making a separate post to describe the process of doing this and its benefits in more detail, so stay tuned for that! But for now, I’ll leave you with this screenshot:

searchengine class
Most of the code has been collapsed from view since it may have sensitive data

Thanks to the new search engine capabilities, I have been able to reuse the SearchEngine class for other new features such as the website’s sitemap. Essentially, constructing the sitemap is done by querying a database for a result containing all the pages belonging to the same category. The SQL code is the same as a user searching (for now though, more about that later), so a SearchEngine object can be used without any problems.

Click here to see the sitemap!

SS Polaris progress
There is finally some progress on my second design project! I have taken a u-turn on the nacelle placement, and I have stripped some details that I thought made the design too advanced. In return, I tried to pepper in some details that make the design both more unique, polished and maybe industrial. Instead of having that weird dual deflector system mounted on top, the nose of the ship has been cut away to reveal one large deflector/communication array that I hope adds emphasis that the design relies on communication (since it is a diplomatic vessel). The new dish is also surrounded by some missile bays. The design will not have any energy weapons.

It’s quite funny, this design was developed without specs and was required to be developed in a week! Yet, it’s taken like two months or so to get to this stage… xD. Hopefully lesson learnt – ALWAYS iron out design specs ’cause it will just cause headaches later on.

Polaris: before (top) and after (bottom)

EXP-type Warp Reactor
I have added a new early UESPA reactor to the database. It is an attempt to explain how and why Earth had a matter/antimatter reactor (on deep space probe Friendship 1) so early on.

You can read about it here!

Progress gallery & milestones article
I’ve added these fun articles to show the progress and effort that was put into Path to 2265. Progress gallery is already up to do (mostly), but milestones still needs it content.

Chapter 1 proofreading
After discovering some grammatical errors on this chapter of the History report, I am currently in the process of thoroughly proofreading it!

Discontinuation of the “Todo” page
In all honestly, the page was only created for myself as a temporary tracker whilst I worked on the website. It was a place where I could list issues when I found them for later solving. Now that I use GitHub for issue tracking and source control, it has become redundant and will be removed from the website soon.

What’s the come!
My main focus is developing the search capabilities further right now. I soon hope to have an intelligent tag search with proper result ordering and sorting.

SS Polaris is nearly completion. So I might roll that out soon. The design documentation for both SS Voyager and SS Polaris need proper attention and revamping.

Chapter 2 (“Space Boomers”) should be completed in the next few weeks too!

And I think that’s that for today!


Adding a basic search feature (repost)

(This is actually a repost since I made an mistake before. Whoops.)

The last three days were about considering and mastering the search feature for Starfleet’s Path to 2265. I write this blog post whilst I ponder ways to made the search feature more powerful and intuitive.

As it currently stands, it is a basic search function. When a viewer submits a search query, and SQL query is searches a database and returns an array of results. An if statement checks to see if there are any results. If there aren’t results present, a ‘no results’ message is echoed. If there are results present, the code proceeds to a while loop that iterates until there are no more results to echo out.

In pseudocode, the operation needed to make a search currently looks like this:

  1. Connect to MySQL Server
  2. Select MySQL database
  3. Create variable for the query string received from the search request
  4. Create variable for the SQL SELECT query that searches for matches within two fields of a database table.
  5. Create variable to store the raw results from the running the SELECT query, and handle possible MySQL errors
  6. If number of raw results is more than zero:
    • While able to print out raw results:
      1. Echo a tile containing the data for the result (includes a hyperlink, page name, category, description, and an optional image)
  1. Else:
    • Echo a tile containing a ‘no results’ message

FYI, a “tile” is the CSS class name I use for the layout element that contains a result or message.

Following that procedure, you can generate results like this…


…from a search box like that:

I have clearly broken the statement I made on my last post about this project saying that I will not be doing any more serious non-styling code! But a search feature is something I should have had from the get-go. There are refinements that ideally need to be made before the website goes onto the internetz; a more advanced search algorithm that can intelligently display relevant results instead of echoing the results in the order they are stored in the database, a more space-efficient results page with filters, and compliant code for when I switch to PHP7 which also requires I use mysqli_* functions instead of just mysql_* or PHP Data Objects (PDO).

Now. Before I end this blog post, below is an example of an implementation of that pseudocode that should work with little modification. Starfleet’s Path to 2265 uses code that is very similar currently. It might be basic, but it works for now. I am more focused on other parts of the website. So if I run behind schedule, I at least have this to fall back on.

Example PHP code:


Example HTML code of a search box that works out of the box with that PHP code:




Ironing out “Starfleet’s Path to 2265”

After an interesting birthday on the 27th where a bunch of friends and I had a debate about the merits and dangers of artificial intelligence, it is time to get back on with life. My Star Trek-themed website is nearing the point where it is polished enough to go on the interwebz. Hopefully, it should be online around the middle of next month once I have purchased the domain name I need.

I have made some considerable chances since my last post about the website (Library, Rain & ul/li menus). I rebuild the code and styling of the website in a complete mobile-first approach, implemented the ul/li menu, and generally added more content ready for launch. For this week, I am currently working on refining the style of the website. As it currently stands:

So far, creating content has been thought-provoking and fun to do! Whilst it may take years to complete everything I want to do, the motivation to do this has allowed me to create a fair bit of launch material ready for next month. Here are some examples:

(Please ignore any spelling, grammar or word flow issues. Everything will be proof read eventually before launch.)

Developing the design to suit the content has been interesting too. As shown by the example of a ship report above (and below in far more detail), I have been developing these ‘boxes’ for different types of content to give the page an LCARS-like (the interface of TNG-era Starfleet computer terminals) feel. I avoided completely copying LCARS due to the fact that this website is based around pre-TOS and TOS content (the similarities are just a ‘tip off the hat’). These boxes do collapse on mobiles and tablets in order to free up space for words.

So that’s about it for this update! Most of the changes from here on will be refinements and additions to the CSS stylesheets and adding more content. One thing to be revised is the colour scheme – the blue seems too intense on some displays. Adding more HTML (except when headings and paragraphs are needed) and PHP code is unlikely.


Why “Mobile-First” website development is actually a good thing

Upon examining my last three websites project, I have noticed a trend in the way I develop websites.

I usually design my websites desktop first/mobile later. Which has been fine until now since these offline projects were just code practice for me, and they were database-style websites that would be ill-suited for mobiles. But now, as I prepare to launch two websites that will be on the internet for the public’s viewing, I am starting to see why the “mobile-first” philosophy is actually a good one, and why modern developers should consider adhering to it.

In the last of the three older projects (which was about Aircraft Carriers), I did start redesigning the website to be content-efficient on mobile displays using CSS media queries, but the transition was troubled. I found my myself ‘hacking’ things to make things appear correctly, rewriting entire CSS stylesheets, and adding DIV containers to manipulate groups of elements better.  On my first new websites, I have opted to start transitioning to a mobile-first development scheme (I’ll explain more about why I finally decided to adopt this approach below).

Things have worked out far better this time around. Probably the best thing about this is that the transition from mobile to desktop is an expansion, whereas the transition to desktop to mobile is a contraction. Making an element contract from an already well-calculated specification can be problematic, hence some cases of rewriting the entire CSS so that everything acts uniformly. Manipulating elements designed to be small into larger elements from my experience is far easier.

The new websites look far better than all my previous efforts. But the change was incremental. The first new website, a Star Trek fan site, was only designed at the beginning with mobile devices in mind. There is a high degree of code commonality with my aircraft carrier website, except for the way I handle content efficiency. You might notice from the screenshots of my website there are these red tile objects. These are what display hyperlinks and other data that require morphing when viewed on smaller screens. Using media queries; their width, height, padding, font-size (in em instead of pixels) and optional images’ size are modified. The rest of the website’s content, such as headings and paragraphs, only have their font-size modified. The header’s size stays the same, although the standard menu gets switched into a mobile “hamburger” menu. The website is designed to be displayed in three fixed size brackets; desktop (> 1024px), tablet (< 1024px && > 768px) and mobile (< 768px). This website is due for launch before the years’ end. I will likely make a future post explaining this project.


(Please note that for the mobile website, a viewport meta tag is present to ensure that a phone’s web browser displays correctly and eliminates the view of that large blue margins. That screenshot is from a desktop browser.)

My second website is eventually going to serve as my personal portfolio showcase. That was written from the ground up to be a mobile size. The default CSS code is for mobile styling, and then media queries modify it to desktop styling when needed. There are also three size brackets, however the during the mobile bracket, the wrapper that usually keeps the elements in the center of the screen is not fixed and the elements can scale to fit from 768px to 480px (before, the mobile bracket offered a fixed wrapper size of 512px). The tile styling system I used previously is currently omitted from the design as I am working on a better way of flexible size data representation. The design is still being built, so no screenshots yet.

So, why this change all of a sudden? Well, the fact is that more internet users are using mobiles these days – I personally have been using my phone to browse my favourite Star Trek websites more than ever. And the fact is, you really should not give your readers a negative point about the website’s design. I have seem some reports and statements that have talked about the woes in the eyes of the consumers when they use their phone to browse a non-mobile optimised website. People are quick to form opinions based on first impressions. And if that first impression is that the website has a poorly-optimised mobile site, then it is possible that no amount of good content will remedy the situation (it is funny, yet concerning how many things you can apply that logic to as well…). But anyway, I aim to give the best impressions I can with my first proper public websites!