Developer's diary

[gene]

Two things still missing from the data model is regional naming, i.e. Super NES in North America and Super Famicon in Japan, and abbreviations like SNES. This should be a little like our title connection for the games, just not this complex.

Okay, let's talk about more details on this.

• you want to classify a platform name. What types are there?
  • Abbreviation
  • Official Title
  • any other?
  • is this optional?
• you want to be able to assign a region to a platform name
  • is this optional? I would suggest that it is optional.
  • what if a name is used in multiple regions? Shal we define multiple transliterated Strings each with one region or one string with (zero to many) regions? I vote for the the latter

[MZ per X]

Would it be good to transform our "GameTitle" object into a general object for holding such "title/name strings" (strings that need to have translations/transliterations attached, and that can be regional)?

Then we'd have this problem in one central place and could link this title object to every other object that needs regional names, abbreviations, nick names, etc., like the GE, hardware/software platforms and sub-platforms.

[gene]

Yeah, this seems to be something that we should centralize somewhere

But let's recall the concrete requirements:

A "TransliteratedString" ("TS") is a collection ob objects with:

• a text
• a script in which the text is written
• a language in which the text is written
• a region where this text is used
• a type (abbreviation, other?) Or is this only a property, let's call it "isAbbreviation yes/no"?

Does this count for all TSes?
Are some fields in some cases optional and in other cases not optional?

Edit:
What do you think about this?

But how does this relate to Tag List 7?

1. Main title (minimum one per language)
2. Common abbreviation
3. Development title / Pre-release title
4. Inofficial title / Nick name
5. Re-release title
6. Budget release title

[MZ per X]

But let's recall the concrete requirements:

A "TransliteratedString" ("TS") is a collection ob objects with:

• a text
• a script in which the text is written
• a language in which the text is written
• a region where this text is used
• a type (abbreviation, other?) Or is this only a property, let's call it "isAbbreviation yes/no"?

Does this count for all TSes?
Are some fields in some cases optional and in other cases not optional?

No, it's a little different. The region and the type are properties of the connection between the TS and the object.

Example (fictional):

We have a TS object with the primary data set:

text = "Diablo"
script = "Latin"
language = "Spanish"

We could add secondary data sets to this TS object:

text = "Teufel"
script = "Latin"
language = "German"

text = "Devil"
script = "Latin"
language = "English"

Then we link this TS to a game object with two additional properties:

"Diablo" ------> Game 1437 with (region = "North America" AND type ="Main title")

Let's assume there will be a console named "Diablo Gaming System" in the future. Then we could link this TS again:

"Diablo" ------> GamingEnvironment 112 with (region = "Worldwide" AND type ="Common short name")

Then, there may be a Spanish print magazine called "Diablo", so we link another time:

"Diablo" ------> Publication 65 with (region = "Spain" AND type ="Cover title")

See? The region and the type are in the link. So far, so good, but there is one problem:

Let's assume there is a German game called "Teufel", too. Then we IMHO cannot re-use the above TS by pointing to the German data set in it.

Instead, we would need to create another TS object with the primary data set

text = "Teufel"
script = "Latin"
language = "German"

and link this to the German game, then probably would add "Devil" and "Diablo" as secondary data sets to this new TS. That would be quite some data duplication, I suppose.

[gene]

Short reply:
In my last post this image should habe been embedded (from this page):


I will reply to your post later.

[gene]

No, it's a little different. The region and the type are properties of the connection between the TS and the object.
...

Ok, I get your points.

Here are my answers:

1. I really think that we don't need to reuse TS instances from GameTitles to Platforms or something similar. This does not happen often and it makes the data model much more complex.
2. I made an updated version of the TS data model and tried to insert your examples for GameTitles and PlatformTitles. But it doesn't work either because now the Region and Type are assigned to *all* text instances of this TSCollection.

Here's the image:


Edit:
I removed the TSCollection, here's the updated version:

[MZ per X]

My point was doing it like this:



Have one table for all the "titles" and link it to everything that needs a title.

If we then add an additional string_id...



we could link a specific table row using the primary key, and identify all the strings within the data set using the additional string_id. So my above example table would look like this:

ID - string_id - text - script - language
111 - 98 - Diablo - Latin - Spanish
2356 - 98 - Devil - Latin - English
10056 - 98 - Teufel - Latin - German

And the links would change to this:

TS 111 ------> Game 1437 with (region = "North America" AND type ="Main title")
TS 111 ------> GamingEnvironment 112 with (region = "Worldwide" AND type ="Common short name")
TS 111 ------> Publication 65 with (region = "Spain" AND type ="Cover title")

And the case for the game "Teufel":

TS 10056 ------> Game 10015 with (region = "Germany" AND type ="Main title")

And these three strings are glued together by their string_id 98, with which we could show translations. For instance, if a German user hovers over the string "Diablo", we could show him that it means "Teufel" in German.

Is this better?

[gene]

Yeah, that sounds quite good.
I did some minor enhancements to the model. e.g. renamed the "Connection" objects and removed the "connection". That makes it more clear I think.


The thing with the "Id" to connect multiple, similar Strings is the only thing I don't like yet. I got your point but I must think about how to model and realise this in a reasonable way.

Can i implement this data model as we have it now (except the "id" thing)?
Want to see it on the running web page

[MZ per X]

The thing with the "Id" to connect multiple, similar Strings is the only thing I don't like yet. I got your point but I must think about how to model and realise this in a reasonable way.

Yeah, I admit it is a bit of a hack. But above all, it's an easy solution to the problem at hand.

Can i implement this data model as we have it now (except the "id" thing)?Want to see it on the running web page

Y E Z Z Z !

[gene]

I tried to clean up the documentation for regional titles / names and the data model so that it reflects our thoughts about TransliteratedStrings from our previous posts in this thread:


Edit:
I also tried to clean up the data model for GamingEnvironments / Platforms.
It looks much clearer than before!
(I changed from "drawn relations" to ID attributes or even "List of ID" attributes to achieve this, so no real changes.)

[MZ per X]

Looks good, thanks! I will try to clean it up some more.

[gene]

I implemented a first version of GamingEnvironments with one/more PlatformTitles (with type and region) which each has a language and a script it is written in.
So it's possible do name GamingEnvironments in a very flexible and detailed way! Where no one has gone before...

Check out the new online development version:





The unterlying data model can be seen here.

[gene]

You can now edit and create GAMEs:





Editing games up to now contains only some major attributes, ReleaseGroups and Gametitles. But that's already cool!

Of course the edit screens are not optimized in any way - they are just a first *working* version.

[gene]

During the last weeks (very warm weather here in Germany) I studied works about something that is named "mobile first" web design.
This is an interesting approach, here are the essences:

• mobile web user numbers are increasing steadily (you can also say: they are exploding)
• main objective is: create websites for small devices first, and afterwards optimize the site so that is displays properly on bigger devices (up to desktop size)
• developing designs for mobile devices first lets you focus in content first, not on (desktop) layout
• search engines start to give higher rankings to sites that work well on mobile devices

If you look at the current Oregami test client on a mobile phone (or resize your browser window), the site does not adopt very well. Some minor things happen with the used bootstrap CSS framework, but e.g. the games list (a regular HTML table) is far too wide to display properly.
Take a look at this supercool test tool, which constantly resizes the (inner) browser window with y given URL
A good example for mobile first design is the Boston Globe Homepage. Change the display size and watch how the site elements change dynamically.

So, at the moment I am experimenting with a completely new HTML / CSS implementation of the Oregami test client. The goal is to creat a navigation with very good mobile experience and also to display the real content in a proper way on small devices. That's even more challenging if we talk about the HTML forms for adding/editing data.

Resources for "mobile first":

• Slides by Luke Wroblewski, the "inventor" of the mobile first approach
• Adventures in Responsive Navigation with some great examples for good mobile navigation menus
• Why should I design for Mobile-first?
• Ish. Testing tool for various web page sizes.
• An Introduction to Mobile-First Media Queries
• 7 Habits of Highly Effective Media Queries

PS:
You might want to try how existing game databases display on small screens (I don't want to be disrespectful, I just want to show what can happen if you don't do mobile-first)

Stay tuned!

[gene]

Currently I am trying to integrate Liquibase.
Wikipedia states this about Liquibase:

Liquibase is an open source database-independent library for tracking, managing and applying database schema changes. It was started in 2006 to allow easier tracking of database changes, especially in an agile software development environment.

Background:
Until today I used an "in memory" database for our server application. This means that every new deployment and/or server restart, the database structure and content is deleted.
This makes it impossible to really go "productive".

So with the help of liquibase the database structure is stored in XML files, which can be executed iteratively. Every database change which is made during the development (e.g. an new table, or a new column to an existing table) is then stored in an additional XML file. On our deployed, official server (and in every development environment), liquibase discovers the current state of the database and only executes the new changes to the database.

This will make development and operation on our server easier!

BTW: Unit tests still use an in memory database.