Bruji

Dear Community,

being relatively new to CDpedia – though I’ve been looking for and trying several apps for the same purpose – I got really excited about the Details View custumization features (since it’s the good old browser pane at all with all its HTML, CSS and JS features), so I have created mine, and named it Strict, since this one is something special that may not be liked by the average user, but, looking at my really strict habit of organizing my own physical CD collection, it really fits my needs.

Question is if anyone is interested in it – first look at the screenshots below, than let me hear you in the comments.

I’m providing the whole downloadable stuff on GitHub. I’d really appreciate if anyone could test it – I’m in the middle of my re-cataloging process of >1200 CDs (“middle” is a polite understatement), so I surely will do the testing on my own collection, but of course it’s just my own one.

For the customized field names and purposes please see this table.



Features

• The layout is based on a slightly modified version of the Responsive Grid System (see landscape and portrait layouts).
• The fields are grouped into different parts (“infoblocks”). These are parts that contain information belonging together – in my opinion (e.g. Purchasing Info, Album Identifiers, etc.)
• The cover image is included in the template (yes, you can simply ignore it with a sudden comment-out keystroke :)) and shows the large size in lightbox. (I know, the same thing applies to the hardcoded cover image preview pane, but this one doesn’t need any new windows).
• The content is post-managed by a massive JavaScript parser, which
  • removes commas from between the taglist elements (the CSS turns them into button-like links),
  • makes track infos (in square brackets) lighter than their main (base) names in the tracklist,
  • replaces default cover with a customized one, and removes (lightbox) link if no cover is provided,
  • puts default text into the "More Info" block's URL description, if it is empty (this is the URL field of an entry),
  • replaces line breaks with paragraphs in the Summary block, and
  • removes empty infoblocks.

Known Bugs

• If the track title is too long and it contains Composer, it looks weird.
• Some small typographical corrections.
• The template doesn’t turn into one-culomn mode when the pane is <480px wide (it hardly turns out by regular usage).

Future plans

• Translation capabilities.
• Instant search for the most fields (Label, Catalog #, etc.) on Google, Wikipedia, Discogs, AllMusic, etc. (maybe through tooltips).
• Borrowing info. I strictly don’t borrow any CDs (books, instruments and wives) to anyone, sorry. Therefore I left these fields out. (Though you can implement it pretty easily when looking into the code.)
• A simple configuration options block in a separate JavaScript file for the shown infoblocks, and some other parameters (e.g. need/don’t need cover image, font size and colours).
• Possibility of (simple) Markdown syntax usage in the Summary section through a JavaScript Markdown parser.

Questions

• - How can I create installable template files? The only instruction for this process in the help files was under the Creating Installation files title on this page telling “You can attach installation files to your templates so they will install themselves automatically in the correct program.” – which is something general, but not so much informative.
  - What if I put the images into the template’s own /img folder instead of the recommended common /Images folder?
  - What should be the folder of supporting scripts named by recommendation? I called it /My_Template_Name/assets, but I have seen some others calling it /includes.
  - And finally: what is DiscID for? :) I mean, this field can’t be the Label Catalog Number (it’s the Catalog # after all), neither the UPC, nor the ASIN or Collection ID – they all have their own fields. Then what? (An example would just be fine.)

So… are you interested?

Download/fork Project on GitHub

That is a really nice template. I like the use of fonts to set the information apart. CSS and web frameworks have come a long way since we last redesigned our own included templates. Soon will have to update our own templates with more advance frameworks like the Responsive Grid System you are using here.

I must update the documentation on templates and installers. I also want to add some Github integration to make future collaboration easier, but that is all further down on the to do list. To answer some of your questions:

- The installer is a package that lets CDpedia install the files within. Here is your template package in the installer as it's simpler to see in action than describe. All the files go in /4.0/WebViewFiles folder and CDpedia will move them into "InfoTemplates". There is also a "WebViewImages" that get moved into the default "Images" folder. If hosted on our server it will even install with [url=cdpedia://download?temp/strict.zip]cdpedia://download?temp/strict.zip[/url], but this is one of the features I want to change and open it up to direct Github installations.

- The images folder is just there as a way to share images among templates, but there is no requirement to use it. And in this case of such specialized design it makes sense to have your own images folder.

- Matter of preference; "assists" reminds me Ruby on Rails development as it's also the name used there. Since we are moving to everything contained in a folder for each template, naming becomes less of an issue when there is no common repository.

- DiscID is a generated ID based on the location of the tracks on the actual physical CD. It's used by grace note (iTunes) and Freedb.com to look up the disc information when a CD is inserted into a computer. If designing CDpedia today it's a field that would be invisible as few users would enter that information manually.

After an hour of use I am really enjoying the tags and the mouse over color change. The only issue so far is I would add truncation (ellipsis) to fields that are to long to fit in a single line, such as composer and producer under contributors can run into each other when there several listed (at least often in my database).

Thanks, Conor.

I decided to create a GitHub repo for the template, it’s the easiest for me and anyone interested in it. I’ll update the original post soon.

Then let’s go backwards.

(…) composer and producer under contributors can run into each other (…)

Yes, I know it. This is among the typographic issues that can be resolved pretty easily, I just want to have at least 50–60 CDs in my database to test the layout on real and existing examples. I’m pretty sure there would be some other bugs too – there’s no such thing like perfect code, which applies to CSS and JS too. :)

DiscID is a generated ID based on the location of the tracks on the actual physical CD.

Gee, I should have known it, thank you! :) It is usually saved with the tracks when I rip a CD (The ripper use to download it from the mentioned sources.)

Since we are moving to everything contained in a folder for each template (…)

Yeah, looking into the templates folder I already thougth, this time should come once. :) Anyway, I have just recreated the whole stuff in the repo. Though I assume “in a folder for each template” means that the template HTML file would be then contained by the folder itself (so that it wouldn’t reside out it, like now), I built my repo for the current situation now, that is I have created a template folder (named “Strict”) and put the Strict.html just beside it. Then – after you have updated the app to handle standalone and separate template folders with all the HTML, CSS, JS and images inside them –, I’ll update my template too.

The images folder is just there as a way to share images among templates

OK. No worriez.

The installer is a package that lets CDpedia install the files within.

Fine. What confused me was the Mac way of handling folders sometimes as if they were files. :) (See “Show Package Contents” in Finder.) So when I downloaded the mentioned template resource, it just appeared like a normal folder in my Downloads directory (don’t know why). Then I suddenly found out, what if I renamed it to something.pediaextras_c (emphasis on _c). Then – ta-dah! – it suddenly turned into a “file”. (Sigh.) So now it’s clear to me: there is no such thing as “template creator script or app or feature of *pedia apps” – you just create the folder contents, name the folder itself something.pediaextras_* (where _* may be the respective app abbrevieation or be omitted as per the doc), and… that’s all. :) Now I still managed my repo the “hand-made way”: the user should pull down the repo from GitHub, and copy the files into the templates folder. Otherwise, with the single-click solution the package contents should go into their default destination – and I didn’t want to be lost testing where the assets from the WebViewImages folder would land. :) Plus I think this structure will be revisited in the next major(?) update.

I must update the documentation on templates and installers (…)

Tell me if I can contribute in something – this app is frankly awesome, I don’t want it to disappear. When I was still on PC, I used CATraxx – as you can see, its development ended sadly, moreover, you cannot even register the newest update directly. I was pleased with that, but then I switched to Mac. (As for the competitors: Librarian Pro is a trash, FileMaker requires building up a database from scratch, and MusicCollector is ridiculous. Anyone else?) (Tell me I’m soft-soaping. :) )