Tim’s Weblog Tim's Weblog
Tim Strehle’s links and thoughts on Web apps, managing software development and Digital Asset Management, since 2002.

Short links (2014-11-26)

Wed, 26 Nov 2014 15:13:26 +0000

Laurence Hart: Chaos Reigns at Content Management Vendors

Laurence Hart – Chaos Reigns at Content Management Vendors:

“Cloud had been dismissed before, as clients hadn’t been asking for the cloud. Customers hadn’t asked because they determined that the legacy vendors were the wrong people to ask.

[…] It wasn’t until last year that they started to realize that a SaaS service was what was truly needed. […] Customers view these offerings as “me too” capabilities that validate the approach of the EFSS vendors.”

Mon, 24 Nov 2014 19:00:34 +0000

Developing software has never been easier

1988: As a teen, I wanted to learn to code but couldn’t afford to buy Turbo Pascal for my Atari ST. Most programming languages (interpreters / compilers) were distributed commercially. There was no Web to download from, someone had to ship floppy disks.

1994: As a student, I loved to have Pascal (commercial but cheap) and Microsoft Access 2.0 (expensive, paid for by my first client) on my Windows 3.1 PC. When I was stuck, I had to consult a book or search CompuServe (a commercial pre-Web community) for answers.

1998: At my job, a few years later, we had Web access (my first Windows 2000 PC was actually permanently connected to the Internet, with a public IP address and no firewall). We built Web-based software, running Apache, PHP, and a database with a search engine on Unix servers. Most database software was commercial, and extremely expensive (we used Oracle). Search engines were hard to come by (we went with Oracle’s ConText). I got my own development server, which means the company bought me a second PC – it took days to install Linux, Oracle and all the other stuff on it.

2014: Today we have virtual machines (easy to clone) we can run on our Mac or PC. Or we run servers “in the cloud”. Databases, search engines, programming languages, editors, you name it – there’s enterprise-grade open source software for almost everything. Plus a vast array of tools and libraries. And people are writing tutorials and posting the answers to almost all our questions on the Web, for free.

With no investment besides Mac or PC hardware and an Internet connection, and a lot of time, I have everything I need to build professional software. An amazing opportunity for learners and independent developers. (Or hobby projects: I’m currently working on a topic maps engine.) No wonder there’s so many Web CMS and DAM products/projects out there.

I keep being amazed by the huge opportunities and the low barriers to entry. (And I keep wondering why so few young people learn programming. You don’t know what you’re missing out on!)

Wed, 19 Nov 2014 07:20:54 +0000

Browsing the newspaper – an unusual DAM feature

Our DC-X DAM software is one of those DAM systems that (while offering general-purpose DAM functionality) focus on the news/publishing industry. For our newspaper- or magazine-publishing customers, publication metadata is among the most important: Name of the publication, publication date, page number, section name etc. (see DC-X publication data, based on the PRISM standard). This metadata applies to pages (usually single-page PDF files), articles (plain or formatted text), images, graphics/logos and ads – which are all stored as separate assets.

While all that metadata is neatly stored in the DAM and highly useful, accessing the newspaper archives within the DAM doesn’t feel like reading a newspaper at all. You have to perform a search to get at the pages, and get back a list of individual assets not optimized for reading page by page.

After a few custom implementations, we’re finally releasing the prototype of a newspaper/magazine browsing view that utilizes the publication metadata. It shows a pair of pages at the top, with buttons to navigate between pages. And it lists the article, image and ad assets that appear on these pages.

It’ll take a few rounds of customer feedback, but I’m confident that we’ll end up with an interface that’s a much more natural fit for our customer’s most valuable assets, their publications!

Fri, 14 Nov 2014 10:18:19 +0000

The business case for machine readable rights

A big question at the recent IPTC Machine Readable Rights Workshop was how to get people to adopt a standard for rights metadata. A “business case” would certainly help: There will often be no budget if machine readable rights don’t save money (or even earn it).

Below is a short list of possible business cases. I don’t have any numbers, but these cases are all coming from our customers – it’s what they considered when deciding whether to invest in rights management software:

Save time when selecting and using digital assets: no need to read the editor’s notes, users see at a glance which assets can be used – or they don’t see unusable assets in the first place.

Buy cheaper assets or reuse the ones you already bought: You can encourage users to choose a less costly, or free, or broader-licensed asset.

Avoid buying the same asset twice. It does happen; users sometimes don’t know that someone else already licensed it.

Save time when processing royalties. This is usually a time-consuming manual process that could be optimized with the help of metadata.

Allow for budgeting – knowing during production, in “real time”, how many royalties you’re currently paying can help avoid excessive spending.

Reduce legal costs. License or copyright infringement can be expensive, and damage your reputation.

Repurpose content more easily, hopefully earning you money via new publishing channels.

License out content to others and earn money. You really need to know an asset’s rights before you can resell it.

Note that it takes more than just “rights” to make this work: The digital assets have to be uniquely identified (duplicate copies with conflicting metadata are bad), their usage must be fully documented (“when did we publish this image?”), and legal issues and contracts must be encoded in metadata (permissions, restrictions, and costs).

Tue, 11 Nov 2014 22:08:04 +0000