Model train database

[KenS]

I'm probably a bit biased to think in terms of books. When I think of a train database, I think of the old Kalmbach Diesel Spotter's Guides that used to be published for North American trains:

 

http://www.amazon.com/Contemporary-Diesel-Spotters-Railroad-Reference/dp/0890242577

 

They're long out of print, but that was my primary reference in the days before the Internet.

[Martijn Meerts]

I have a couple of train books as well, but I hardly ever open them (one of the reasons would be that there's almost no Japanese trains in them ;))

 

 

Anyway, made some more changes. Made a new mockup of the the "available models" tab, added thumbnails and more space, needs some more changes though (bigger thumbnails? short description?) Also added a mockup of the related items tab, with a drop down to pick form various relations (type, depot, company, year, colors, etc. etc.. Need to make a list of useful relations =)). Like the models tab, it might need bigger thumbnails. There's also the "prototype specifications" tab, but that one definitely needs some photoshop loving =)

 

Also slightly updated the breadcrumbs bar, as well as removed the little triangle that indicated which menu item was active. Not sure it should be there, even though I did quite like the look of it.

[Martijn Meerts]

Made a quick XHTML version of the main site. It's all very temporary just to see if things work without resorting to a billion different browser hacks. Works fine in Safari and Firefox on the Mac, and it seems it works fine on IE8 as well.

 

Now to add more detailed stuff =)

 

http://www.jr-chiisai.net/_div/traindb/site/

[CaptOblivious]

TThe The menu sidebar moves left and right, which means it jumps in front of the conent of the window is too narrow, as on my Android phone. Otherwise appears to render correctly (and it should: android uses safari's rendering engine)

[Martijn Meerts]

it's not mobile friendly, there'll be a completely different UI for mobiles =)

 

And while Android does use Webkit, they've done a lot with it.. iPhone Webkit renders different from Android Webkit, which renders different again from desktop Webkit (which themselves render differently from 1 browser to another ....)

 

That said, it does seem to work as intended on the iPhone..

[CaptOblivious]

Same problem on my small monitor at work. It's not a function of the phone, but rather of a small screen size, and having the menu pinned to the upper-left-hand corner of the viewing window. If the window is narrow enough to require scrolling to see all the content, the menu ends up on top of the content as you scroll to the right…any way to pin it just to the top, but have it scroll horizontally with the other content?

[Martijn Meerts]

Ah, I see the problem now...

 

I don't think it's an easy fix, however, this version of the design is meant for the newer browsers which often go hand in hand with higher resolution screens. This version will get css3 animations and the like. I've actually been considering making this version a bit wider even, because it looks a bit silly on a 1920x1200 screen right now :)

 

I'm probably going to eventually make a simplified version for older browsers and lower resolutions.

[Martijn Meerts]

http://www.jr-chiisai.net/_div/traindb/site/

 

Added/updated a bunch of stuff, can't even remember what exactly since the previous preview =) I made certain bits and pieces clickable, the tabs have gotten some content to get an idea of how it could look. I added dropdowns to gallery and related tab, especially the one on the related tab is fairly custom. Also added some flags for language selection. (Language selection is mainly done by subdomain, but with a flag you can always quickly switch.)

 

I've tested it in Safari, Firefox, Camino and Chrome on OS X, haven't tested in any browser on Windows yet, so it might actually look terrible =)

 

In the background, I'm designing the database now, and figuring out how internationalization and localization work in Rails. I've pretty much got that figured out though.

[Martijn Meerts]

http://www.jr-chiisai.net/_div/traindb/site/

 

Been a while since I last worked on it, had some other stuff to learn for work first (I really need to stop prioritizing work before other things during my spare time ;)), but I've made some changes to the design again.

 

I changed the menu so that it's no longer pinned, and will actually scroll along with the content. This fixes the problem Cap mentioned about the content being moved underneath the menu on smaller screens. Of course, the menu will now scroll vertically, meaning it won't remain visible at all times. I might look into some javascript to pin it vertically should I decided I want it to be pinned at all.

 

I also made the entire main content a bit wider. With widescreen screens quickly becoming the standard I figured it made sense to use more screen real estate. The minimum screen width required to view without horizontal scrollbars is now 1280 pixels.

 

Lastly, I darkened the background on the content window. After seeing the design again after a few weeks of not working on it, the one thing that jumped at me was that the background was too light.

 

 

Other than that, I've been trying to design the perfect database and haven't actually started coding yet. By now, I'm pretty certain even database design guru's aren't going to be able to design the perfect database for Locowerks, considering not all features and details are decided on yet. So, I really should just start with a basic database, and add stuff when needed, which is exactly what I'm planning on doing soon-ish ;)

[cteno4]

Martijn,

 

hey looking nice! this ultimately could be a really really great resource for the hobby community!

 

on the 1280 pix you might want to trim that down a little. in the last year there has been a lot of feedback from laptop users that websites have crept too wide in the last year or so and caused them to have to do too much horiz scrolling, which is the worst to do in the UI for most folks. just a thought. your left nav links are thing that dont look like they may needed all the time for fast access so could move up top perhaps and explanations be in roll overs (they are also things that the users will know very soon and pretty self explanatory)

 

the tabs have a nice feel and the main screen width looks good to hold the tab data. any long blocks of text should keep the text width to average of 12-15 words per line. this is a good reading length for extended reading. if you go wider it slows folks reading slows down and shorter looses on comprehension. sorry worked on cdrom encyclopedia projects where we had to do a whole lot of testing and research on stuff like this!

 

its really coming out nice! thanks for all the hard work on this, it aint easy to put your arms around a beast like this, sounds easy till you jump into it! your logic of doing the core first is very wise, every large db project i have been around that tired to tackle the world in the first rev got really bogged down and became monsters that sucked way more time and money than they should have (and i felt like shooting myself in most of the design meetings!). those that went at the core things that were just the main things that were needed most of the time and did those well got done pretty quickly. it was also amazing how many of the other wish items fell by the way side once the core was done -- folks realized they really did not need them or the time to get information structured into those items would have been huge. also, a number of very unique and unpredicted needs popped up that were really great for the workflow and were easily then added to the interface or as additional modules for use by only the subset that needed those features (and thus not confusing or getting in the way of those that didnt need them).

 

great work!

 

cheers

 

jeff

[Martijn Meerts]

The reason I went with the menu on the side instead of at the top, is because most, if not all, menu items will have submenu's. Of course, that would also be possible with the menu up top, but you usually end up doing some strange javascript drow down menu, which I'm trying to avoid. Screen resolution statistics show (in January 2010) that people having 1280x1024 or higher are now in the majority, which is mainly due to most laptops now sitting at 1280x800 or more. Of course, there will always be people on 1024x768, or even 800x600, but at some point it just becomes too problematic, or visually less appealing to optimize a site for 1024. Also, there comes a time where you just should really look forward, rather than try to be compatible with everyone and everything ;)

 

What I'll be doing, is making 3 templates for the site. The first one is the one I'm working on now, which will include some css3 animations (not to worry, they'll only be slight animation to make the UI look a bit more smooth :)) and javascript (in the form of ajax, jquery, jqeury ui etc.), so I'm fairly comfortable with the 1280 minimum.

 

The second template will be a slightly cut down version, something like you suggested with the menu moved to the top, and then the generally design kept the same, so using the full width for the content panel. This version will also stick with older technologies and not use any fancy stuff.

 

The third template will be a mobile design. This might actually turn into more than 1 additional template, 1 for iPhone, 1 for iPad, 1 for android, 1 for windows mobile 7, and of course blackberry and palm devices handle things differently again (mobile web is kinda like regular web was 10 years ago when everyone and their dog built their own browsers ;)) This web version has very low priority though ;)

 

The good thing about Ruby on Rails is that it keeps back-end code separated very nicely from visual code, so it's easy enough to make additional templates.

 

 

The bit about the 12-15 words per line is interesting, it's really something I wouldn't even have thought about researching. Something worth looking at. Easy fix would be to increase the font size a little, maybe add some more letter spacing as well. I'll also have to try different fonts, some read easier than others. Right now I'm using Tahoma for the description texts, and it cascades back to Helvetica, Verdana, Arial and finally the standard sans serif. One thing that's nice about css3, is that you can use non-standard fonts, and the browser will automatically download them so the page looks as the designer meant it to look. So, searching for a font that's optimal for on-screen reading could be a good idea. I've also made the text background just slightly off-white, and the text itself a very dark grey, makes reading easier on the eyes as well.

 

 

The plan now (while still fine tuning the design) is to start with a database table for prototypes, and add all the required code to browse the prototypes. That allows me to have a system where I can start testing the UI, and work on things like decent searching and filtering features etc. After that I'll add the tables for the models, and then start hooking up some models to the prototypes, and fix and optimize whatever issues result from that. After that the next bit will be added (spare parts list, related image/video's, etc.) I should be able to concentrate on small chunks when working like that.

[cteno4]

yes its that statistic that the 1280 is now in the majority which has driven the move to really wide pages, but its getting blowback from a good chunk of the community and its one of those things that if you piss off a group then you may really loose them with a trade off of just making something a little better for others that would probably not be pissed off if you didnt do it. always the trade off.

 

the other issue with wider designs is that if forces many interfaces to have to have 3 and some times 4 columns of stuff and it can get really visually busy and distracting. marketing types like this as they think it looks like there is a lot of stuff going on, but with the users it usually just gets very distracting to the eye and its harder to hilight what is really important!

 

also remember that the window eats some space up horiz and folks usually dont run maximized until forced to. many like having space to move to things behind the main window.

 

its always a juggle.

 

on the text, dont widen the spacing, that just gets harder to read. most auto kerns/spacing are pretty good and done to maximize the reading as well. you can just reduce the text widths of large blocks of text easily in your sub screens. readability is something that is always overlooked and its only getting worse these days as folks are more distracted and if the reading gets hard they just move on. if you want them to stay make it as easy as possible to read. stick to the standard fonts as most of them are very readable and designed for screen reading (like verdana and arial). helvetica doesnt work well as a system font as its tight and really requires some finer resolution. good for when you need to squeeze something in, but not good for large reading blocks.

 

ah didnt realize there would be subs under the left menu. yes the java or css pull downs are a mess to deal with. they really really piss off a sub population as well that hates things popping up when they roll over them. also in some permutations they can be really hard to use and its a total moving target to maintain them well in the whole host of browsers up there. this has driven a few good web developers out of the field as trying to keep bells and whistles like this functioning in all platforms/browsers all the time ends up being very costly and clients want it, but wont pay for it! really a mess. could the sub stuff for the left hand items just come up in the main content area instead? they seem like stuff that is more independent of the content stuff and items you wont need up on the screen all the time, just once and a while and while doing those you will be focused on those things and not the content. that left hand column is in the #1 eyeball spot so anything there should be stuff you want folks to really focus on. to me its the content you really need to focus on or perhaps a cascading nav tree of the trains, but admin, tools, language, and log in are items you only do once a session at most then dont deal with again.

 

tell me to shut up if you want on this stuff. i just do this all the time in my work and also usually end up being the producer so end up worrying about all these little things that everyone else on the team knows, but doesnt always pay attention to till it bites us in the ass later.

 

cool to roll out a tab at a time. you will probably find one major bug early on that once you figure out the work around it will make all the others go smoother! worse when you have to fix or re-engineer in a number of modules!

 

cheers

 

jeff

[Martijn Meerts]

First of all, the comments are very welcome. I could build it like I think would be the best, but it's probably going to end up being more difficult to use for others, because I do tend to move more towards little unnecessary design bits rather than stick to pure easy of use :)

 

 

Right now, the main content area is 800 pixels wide. The entire width with menu and the margins both left and right is about 1170 pixels wide. I like the main content area to be big, because it's all about the content. I increased it by 200 pixels from the previous version, because I felt it wasn't big enough, especially the tabs felt a bit too cramped. However, it might be a bit too wide now with regards to the whole 15 words per sentence. Increasing the font size just a little bit seems to help there though.

 

With regards to the subitems, the idea was the following:

 

Login/register - Several user stats and quick links to personal collections, possibly smart collections etc.

 

Explore - quick links to explore prototypes, models, decoders, buildings, track, and whatever else will be added down the road.

 

Tools - Links to little tools like CV bit calculator, LED resistor calculator, maybe something like analyze an image and find items with similar colors etc. Eventually maybe also links to any programs/apps.

 

Admin - Quick links to admin tools.

 

Obviously, all of those could easily be moved into the main content window instead of using submenu's for them. A user would need a pretty extensive homepage, so the submenu for login/register would probably not be necessary.

 

Explore could be done in a similar fashion as how you set up a smart playlist in iTunes, or how you edit rules in Mail (a predicate editor as Apple calls them.) Before a user enters search/filter options you could display a few random items somehow, or maybe the latest xx added/updated items.

 

Tools could also easily be moved into the content with, either using tabs to quickly switch between various tools, or some sort of teaser image for each tool.

 

Admin is really only visible to admins, or actually not visible at all usually. There'll probably be an admin.locowerks.net with a separate admin user login, or at least some additional security. I'm also considering of doing a totally different interface for the admin part.

 

The language flags could also be removed, and use something like nl.locowerks.net for Dutch, uk.locowerks.net for British, us.locowerks.net for US English, etc. As an extra, a language option could be set in the user preferences.

 

 

I'm gonna have to check if I can get it to look decent with the main menu up top, always difficult to do something that doesn't look like a complete rip-off from the billion other sites =)

[cteno4]

Right now, the main content area is 800 pixels wide. The entire width with menu and the margins both left and right is about 1170 pixels wide. I like the main content area to be big, because it's all about the content. I increased it by 200 pixels from the previous version, because I felt it wasn't big enough, especially the tabs felt a bit too cramped. However, it might be a bit too wide now with regards to the whole 15 words per sentence. Increasing the font size just a little bit seems to help there though.

 

yeah the best with normal sized fonts for general reading is at somewhere in the 600-700 pix wide range. this generally works well with a 200 pix nav column to come out a decent width for most web/cd things. also ends up wide enough to fit in a decent sized photo if you want to wrap text around the photo w/o the photo being too small or the text not get into a tiny 3 word per line column next to the photo...

 

its been interesting as mobile is forcing the other extreme and old newspaper design is slowly coming back as that traditionally had to work with tight columns of text! actually effects kerning and writing and editing as well to work in those short word lines.

 

cheers

 

jeff

[brill27mcb]

I keep my webpages at 700 pixels wide. The advantage is that it prints out looking the same as it does on-screen.  -- Rich K.

[Martijn Meerts]

I keep my webpages at 700 pixels wide. The advantage is that it prints out looking the same as it does on-screen.  -- Rich K.

 

That's actually a very good point. There's a fair chance people will want to print out pages fothe database, so it'd be nice that the page looks good when printed. Of course, there's also the printer friendly version thing, which might be something I'll want to add at some point.

[Tecchan]

I keep my webpages at 700 pixels wide. The advantage is that it prints out looking the same as it does on-screen.  -- Rich K.

 

I would never want to make a webpage with consideration for those who print them.

It's like making a brochure or a leaflet thinking about the guy who will xerox it or fax it. In 2011 we don't need to print webpages. At worst, just make a print stylesheet.

No offense.

 

1280 is wide, but when you look at it closely, you'll see that the content area is only 1100px wide, people with wider screen will see the rest of the page and people with screens up to 1100px won't have any problems to see it.

Maybe you could cut the 1000px away for being comfortable with 1024px screens, but on my point of view, that's not a problem. :-)

 

For the blocked menu, maybe you can make it scroll until it touches the top of the page end then it's fixed, so it still has a nice look on the landing page but you also have the menu accessible from everywhere. You can probably do that with simple JS or even CSS min-height/max-height properties.

An example here: http://2009.maxvoltar.com/articles/

When you scroll down, the logo appears from under the top bar and it's always on the right.

 

My little design advice: some rollover on the buttons (both on the sidebar and top-breadcrumb) would really make the navigation pop-out and the whole design slicker.

The user must feel a reaction when he hovers and clicks the links.

 

I really like you design, I hade quite a same idea for... a train related blog.

Maybe you'll hear about it some day! :-)

[Martijn Meerts]

Kumo, the Maxvoltar site has the same issue as I had with the menu. It used to be fixed so it stay on-screen at all times. However, if you scaled down the browser window far enough to get horizontal scrollbars, and then scroll to the right, the entire content will move underneath the menu. The Maxvoltar site does exactly the same if you scale it down enough. Of course, the whole minimum screen size comes into play here again, and the whole discussion coming with that.

 

As for rollovers and small animations, they will be added at some point, but I didn't want to spend any time on that before I'm certain I want to continue with a certain design.

 

 

What I've done, is make a couple of mockups to quickly compare without having to do any coding. While I was at it, I also changed the width of the main content bit to 700 pixels. Not because of the print thing, but because of the words per line thing ;)

 

 

Mockup 1:

Original side-menu design in a browser window that's maximized to about 1024x768.

 

Mockup 2:

Original side-menu design in a browser window that's maximized to about 1280x1024.

 

Mockup 3:

New top-menu design in a browser window that's maximized to about 1024x768.

 

Mockup 4:

New top-menu design in a browser window that's maximized to about 1280x1024

 

 

Mockup 1, while doable, just doesn't look right. Mockup 2 on the other hand looks pretty good to me.

Mockup 3 and 4 don't really show much of a difference, except that 4 obviously has more darkness surrounding the content.

 

Right now, I'm leaning towards using the side-menu design for the all-out version, and the top-menu design for the somewhat more old browser compatible version. A bit more work perhaps, but it shouldn't be too bad as long as I keep it in my from the get-go.

[Martijn Meerts]

Quick update on this. I've started the actual programming of the site, starting with listing prototypes. I'm also already adding easy to figure out links and general user-friendlyness. For example: locowerks.net/list/country/japan will list trains by country, with the country being Japan. locowerks.net/list/country/us would of course list all trains for the US. In a similar would, locowerks.net/list/region/hokkaido would list Hokkaido trains, locowerks.net/list/operator/jr-east would list all JR-East trains etc.

 

I'm also keeping multi-language in mind, there's already a system in place for interface texts, and I'm looking at some possibilities for article translations. I do think I need to set some limitations here, with the main thing being that an item has to exist in an english version first, before translations can be added (english being the main fall-back language). I also think the permalinks (so, locowerks.net/prototype/series-800-shinkansen instead of locowerks.net/prototype?id=5253) should be english only, and not have a different permalink for each language.

 

Once I get those things in place, I'm gonna look at user login, and the ability for users to submit new prototypes and upload images etc. Still plenty work ahead, but it's quite fun working with Ruby on Rails, especially since I tend to be "on Rails" myself while working on it ... (I usually work on it in the train while traveling to and from work ;))

 

 

Hopefully the place I'm hosting the VPS at is going to offer some new turnkey linux images, so I can upgrade to Rails 3 on the VPS without having to install from source. Once they do, I can put up my dev version on the VPS, and you can start going through a working (albeit unfinished) version.

[keitaro]

How is this going for you?

 

Wouldn't mind jumping in the beta and adding some of my locos details for assembly / unassembly

 

And feedback

[Martijn Meerts]

I'm still trying to work out some back-end and database design decisions and trying to figure out what kinda data needs to go in the database, and which parts of that data need to be translatable.

 

I mainly work on it on the train to and from work, but recently it's been getting more crowded on the train, which means using a 17" Macbook Pro is difficult without putting the thing on the lap of the person sitting opposite myself :) I'm looking at getting a 13" Macbook Air next week in the US though.

 

Also, since I'm working on this by myself, some decisions take a while. I have my own view on how things should look, but that's not necessarily the best way. So I try to look at each problem from multiple angles and try to figure out how which direction to go.

 

 

It's still being worked on though, but I'm taking it a bit slow and easy so I have something that people actually want to use, rather than some system that's too complicated for the average user.

[keitaro]

Fair enough keep us updated on any progress

[Martijn Meerts]

I will.. I'll be in the US the upcoming week, visiting some people of the forum, and the JRM layout at the cherry blossom festival. I'll likely discuss the database with 1 or more of them during my time there to get more views on the whole project.

 

It might be I'm thinking too big, and that the database doesn't need much of the details I think it should need, or at least, it might not need the details in the first version. It's a bit difficult to explain things without seeing how the site currently works, but I can't put it online yet. I'm still waiting for my host to make some new VM's available for the VPS I'm hosting there. The current VM makes it too difficult to install the requirements for Ruby on Rails 3, the new VM however comes pretty much pre-installed with everything.

 

 

The project is definitely not dead, it just needs a couple of fresh eyes looking at it :)

[Tecchan]

Hey, I thought about you when I saw this site: http://trainspo.com/

 

An add was displayed to my on my facebook page, they know me! ;-)

[Martijn Meerts]

Hey, I thought about you when I saw this site: http://trainspo.com/

 

An add was displayed to my on my facebook page, they know me! ;-)

 

That's definitely something I can look at at least :) It looks like they're all about the prototype, whereas my main focus is the models :)