<?xml version="1.0" encoding="UTF-8"?><rss version="2.0" xmlns:content="http://purl.org/rss/1.0/modules/content/">
  <channel>
    <title>musetech &amp;mdash; The SMK Blog</title>
    <link>https://blog.smk.dk/tag:musetech</link>
    <description>Welcome to the highly official blog of SMK.</description>
    <pubDate>Fri, 22 May 2026 01:05:28 +0000</pubDate>
    <image>
      <url>https://i.snap.as/XNBAU2lz.png</url>
      <title>musetech &amp;mdash; The SMK Blog</title>
      <link>https://blog.smk.dk/tag:musetech</link>
    </image>
    <item>
      <title>Finally: A new website for SMK</title>
      <link>https://blog.smk.dk/finally-a-new-website-for-smk?pk_campaign=rss-feed</link>
      <description>&lt;![CDATA[SMK.DK: On 15 August 2018 SMK gets a new website. Here are some of our modest thoughts behind it.&#xA;&#xA;!--more--&#xA;&#xA;The websites of museums — and most other institutions — are strange beasts. On the one hand, our audience simply expect them to exist and to work and to serve their needs. Apart from those (crucial) concerns, they obviously care very little about organizational strategy, editing privileges, design trade-offs or indeed the affordances of your particular CMS.&#xA;&#xA;On the other hand an institutional website of any size is the inevitable source of deep internal discussion, painful compromise and quite a bit of organizational soul-searching. Who are we? What is most important for us? Who is the audience we mostly want to speak to?&#xA;&#xA;In other words: Websites are really hard, and demand for them is very indirect.&#xA;&#xA;Which is not at all to say that they don’t matter. SMK has around 1000 physical visitors and around 2000 website visits per day. 36% arrive through the front page and many check out what’s on offer and scroll through details of entrance fees, opening hours etc. What they see inform their decision whether to go or to opt for one of Copenhagen’s many alternatives. Thus, unsurprisingly, a key function of museum websites is to inform and attract.&#xA;&#xA;Websites can do something else. An optional and by no means universal objective is to use the website to achieve the museum’s core goal itself, i.e. to provide experiences and to educate. To be, if you will, another interface to the collection and related resources.&#xA;&#xA;Interestingly, the general ambition to use the website to extend the museum experience seems to have waned in recent years for many museums. With very notable exceptions we are re-entering the age of the business card museum website: Here are the opening hours, come visit us soon. Explanations for this shift are manifold but one very obvious and indeed honorable reason is the rise of platforms with far more impressive reach such as social media or Wikipedia. It makes simple, practical sense for many to keep the website pragmatically nimble and to let the collection enjoy enthusiastic visibility on your Facebook page (as long as your collection is respectable and non-nude, of course).&#xA;&#xA;Art on Facebook. Often works well, leading many museums to downplay the collection on their own websites.&#xA;&#xA;At SMK we want to inform and attract. But we also want to broaden the accessibility and use of the collection as widely as possible. First of all, our collection contains 260.000 works of which less than 1% can be on physical display at the same time. Secondly, we’re the Danish national gallery and have an obvious obligation to make the collection as relevant and accessible as possible to all Danes, no matter how far they live from Copenhagen.&#xA;&#xA;In the following, I’ll explain some of the practicalities of how we plan to meet this grand ambition. But first, a bit of historical and technical context.&#xA;&#xA;The former website&#xA;&#xA;The former (i.e. pre 15 August 2018) website was launched in 2010 on the TYPO3 CMS platform. It was highly ambitious and involved a wide range of staff members in content production. It allowed the user to search the collection database, although with a modest number of images in fairly low resolution. Though complex in its information architecture (and extremely complex in terms of backend user-experience) it was technically simple as it did not integrate with other systems (beyond search in the collection database) — i.e. there was no webshop, no online ticket sales, no automatic update of staff details, no direct booking of tours etc. A modest number of later revisions included social media sharing features (later removed), improved collection search and a mobile version of certain content types.&#xA;&#xA;The former website — from 2010&#xA;&#xA;In 2018 we’ve had the mobile revolution and its dramatically wide-ranging implications for digital design. From this perspective our former website looks like something of a relic.&#xA;&#xA;The design is non-responsive. Having been designed in 2009 the site has never heard of the wonders of responsive webdesign which adapts all design elements to all relevant screen types.&#xA;Everything is just so small. Not un-typically for its time, it tries to fit everything on the user’s screen. It also uses a large automatic slider to push even more content above the screen “fold”.&#xA;It is quite nonsocial. Content does not share well on social media due to inconsistent markup and lack of meta-tags.&#xA;&#xA;Content page from the former website&#xA;&#xA;All these things are deal-breakers. But equally important, the site’s tall ambitions are laid squarely on the shoulders of human editors.&#xA;&#xA;The idea here is that human beings would spend a tremendous amount of time editing a wide range of widgets, news items, lists, blogs and other contents while the CMS itself would be relatively unhelpful.&#xA;&#xA;Thus, in hindsight, perhaps the biggest problem of the website has been its over-reliance on manual labour and its under-reliance on all the things a computer can actually do if the content model is carefully thought out.&#xA;&#xA;Hindsight is such a powerful thing.&#xA;&#xA;The new website&#xA;&#xA;The new website springs into existence under the auspices of the SMK Open project, supported by Nordea-fonden. Briefly, the project aims to make the SMK collection digitally accessible, relevant, and useful to as many people as possible. Access comes in two parts: Human-readability and machine-readability. Human-readability means the website while machine-readability means our API, of which more in later posts. The website is the museum’s best attempt at a general, digital, visual interface to everything we have and as such it is a key component in our digital strategy.&#xA;&#xA;Front page of the new website&#xA;&#xA;This new wondrous thing is introduced in two stages. The first stage, launching now, rethinks SMK’s digital design (our visual identity has not been systematically digitized before) and our content. It divides SMK content into:&#xA;&#xA;Content pages (e.g. “The history of SMK”)&#xA;Exhibition pages&#xA;Events&#xA;Artworks&#xA;Staff members (which are content items and can therefore be used across other pages)&#xA;&#xA;Each content item is assigned a number of categories (defining the general topic, e.g. “Conservation”) and a number of tags (defining specifics, e.g. “Henri Matisse”). This taxonomy then helps us generate dynamic lists and collections of content across the site.&#xA;&#xA;“Current exhibitions” on new website. The page consists of automatically generated full-screen links to other pages.&#xA;&#xA;In terms of process, defining a start date is always somewhat arbitrary. But actual planning started when we teamed up with digital agency 1508 almost exactly one year ago. Working from our quite flexible specifications, 1508 has provided UX, design and the actual development and led us through workshops and continuous demos and discussion. We have been heavily involved and have provided continuous feedback at almost every level.&#xA;&#xA;One rare nearly set-in-stone decision was our choice of Wordpress as CMS. Although any choice of CMS comes with strings attached, we strongly feel that Wordpress is appropriate for us. While, our desire for complex use of content items across the site might seem to point to systems with more powerful data models, the accessibility of the Wordpress backend and the fact that it is virtually a Danish museum standard (meaning very little need for staff training) are much more important to us. Notably, though, our implementation is “headless”, meaning that we are using Wordpress more as a data repository than a front-end-generator.&#xA;&#xA;IIIF and the SMK taxonomy&#xA;&#xA;The website does two things that are not immediately apparent, but that are important building blocks for our future work.&#xA;&#xA;Firstly, it implements a connection to our asset management system, allowing us to implement a IIIF viewer for large reproductions of artworks. The IIIF standard is quickly becoming a popular way to display and share images across cultural institutions and we are quite thrilled to start down this path. For the user, it means the ability to zoom easily and quickly into artworks using the tiling logic, known from Google Maps, where you dynamically load only the part of the image that you need to see, and not the entire, enormous world map. For scholars, this also means the ability to display images from different institutions simultaneously for comparison and analysis.&#xA;&#xA;IIIF viewer showing details of an Anna Ancher painting.&#xA;&#xA;Secondly, Wordpress will function as our “taxonomy hub”. It will make the tag taxonomy available to other systems, thus allowing us to use it across all our platforms and thereby tie all our disparate content elements together. Ideally, when you see a piece of SMK content online in the future it will be automatically related to all other relevant pieces of content (videos, audio, research articles, images, blog entries…). This will be revolutionarily different from the current situation where finding those links can resemble detective work.&#xA;&#xA;Level one completed, get ready for level two&#xA;&#xA;I mentioned that the website is stage one. Stage two (hopefully launching about a year from now) will present the collection in its full, interrelated, high-res glory. We are already hard at work figuring out how to best display everything — thankfully the #musetech community has shared many inspiring thoughts over the years that we’ll greedily draw upon.&#xA;&#xA;Get in touch!&#xA;&#xA;We heartily invite you to check out our new website. As you can imagine our list of bugs and ideas for improvement is already awe-inspiring, but we do genuinely welcome all sorts of feedback. In particular we’d love to know: Is this a place you feel like exploring (physically or digitally)? And how can we make everything even more inviting, interesting and useful for you. Thanks for clicking.]]&gt;</description>
      <content:encoded><![CDATA[<p><strong>SMK.DK: On 15 August 2018 SMK gets a new website. Here are some of our modest thoughts behind it.</strong></p>

<p><img src="https://i.snap.as/IJmESPY4.webp" alt=""/></p>



<p>The websites of museums — and most other institutions — are strange beasts. On the one hand, our audience simply expect them to exist and to work and to serve their needs. Apart from those (crucial) concerns, they obviously care very little about organizational strategy, editing privileges, design trade-offs or indeed the affordances of your particular CMS.</p>

<p>On the other hand an institutional website of any size is the inevitable source of deep internal discussion, painful compromise and quite a bit of organizational soul-searching. <em>Who are we</em>? <em>What is most important for us</em>? <em>Who is the audience we mostly want to speak to</em>?</p>

<p>In other words: Websites are really hard, and demand for them is very indirect.</p>

<p>Which is not at all to say that they don’t matter. SMK has around 1000 physical visitors and around 2000 website visits per day. 36% arrive through the front page and many check out what’s on offer and scroll through details of entrance fees, opening hours etc. What they see inform their decision whether to go or to opt for one of Copenhagen’s many alternatives. Thus, unsurprisingly, a key function of museum websites is to inform and attract.</p>

<p>Websites can do something else. An optional and by no means universal objective is to use the website to achieve the museum’s core goal itself, i.e. to provide experiences and to educate. To be, if you will, another interface to the collection and related resources.</p>

<p>Interestingly, the general ambition to use the website to extend the museum experience seems to have waned in recent years for many museums. With very notable exceptions we are re-entering the age of the business card museum website: <em>Here are the opening hours, come visit us soon</em>. Explanations for this shift are manifold but one very obvious and indeed honorable reason is the rise of platforms with far more impressive reach such as social media or Wikipedia. It makes simple, practical sense for many to keep the website pragmatically nimble and to let the collection enjoy enthusiastic visibility on your Facebook page (as long as your collection is respectable and non-nude, of course).</p>

<h6 id="https-i-snap-as-2closajn-webp-art-on-facebook-often-works-well-leading-many-museums-to-downplay-the-collection-on-their-own-websites" id="https-i-snap-as-2closajn-webp-art-on-facebook-often-works-well-leading-many-museums-to-downplay-the-collection-on-their-own-websites"><img src="https://i.snap.as/2cLosAJn.webp" alt=""/>Art on Facebook. Often works well, leading many museums to downplay the collection on their own websites.</h6>

<p>At SMK we want to inform and attract. But we also want to broaden the accessibility and use of the collection as widely as possible. First of all, our collection contains 260.000 works of which less than 1% can be on physical display at the same time. Secondly, we’re the Danish national gallery and have an obvious obligation to make the collection as relevant and accessible as possible to all Danes, no matter how far they live from Copenhagen.</p>

<p>In the following, I’ll explain some of the practicalities of how we plan to meet this grand ambition. But first, a bit of historical and technical context.</p>

<h2 id="the-former-website" id="the-former-website"><strong>The former website</strong></h2>

<p>The former (i.e. pre 15 August 2018) website was launched in 2010 on the TYPO3 CMS platform. It was highly ambitious and involved a wide range of staff members in content production. It allowed the user to search the collection database, although with a modest number of images in fairly low resolution. Though complex in its information architecture (and extremely complex in terms of backend user-experience) it was technically simple as it did not integrate with other systems (beyond search in the collection database) — i.e. there was no webshop, no online ticket sales, no automatic update of staff details, no direct booking of tours etc. A modest number of later revisions included social media sharing features (later removed), improved collection search and a mobile version of certain content types.</p>

<p><img src="https://i.snap.as/saS3aSIo.webp" alt=""/></p>

<h6 id="the-former-website-from-2010" id="the-former-website-from-2010">The former website — from 2010</h6>

<p>In 2018 we’ve had the mobile revolution and its dramatically wide-ranging implications for digital design. From this perspective our former website looks like something of a relic.</p>
<ul><li>The design is non-responsive. Having been designed in 2009 the site has never heard of the wonders of responsive webdesign which adapts all design elements to all relevant screen types.</li>
<li>Everything is just so small. Not un-typically for its time, it tries to fit everything on the user’s screen. It also uses a large automatic slider to push even more content above the screen “fold”.</li>
<li>It is quite nonsocial. Content does not share well on social media due to inconsistent markup and lack of meta-tags.</li></ul>

<h6 id="https-i-snap-as-qhxs3yvy-webp-content-page-from-the-former-website" id="https-i-snap-as-qhxs3yvy-webp-content-page-from-the-former-website"><img src="https://i.snap.as/QhxS3yvy.webp" alt=""/>Content page from the former website</h6>

<p>All these things are deal-breakers. But equally important, the site’s tall ambitions are laid squarely on the shoulders of human editors.</p>

<p>The idea here is that human beings would spend a tremendous amount of time editing a wide range of widgets, news items, lists, blogs and other contents while the CMS itself would be relatively unhelpful.</p>

<p>Thus, in hindsight, perhaps the biggest problem of the website has been its over-reliance on manual labour and its under-reliance on all the things a computer can actually do if the content model is carefully thought out.</p>

<p>Hindsight is such a powerful thing.</p>

<h2 id="the-new-website" id="the-new-website"><strong>The new website</strong></h2>

<p>The new website springs into existence under the auspices of the <a href="https://www.smk.dk/article/smk-open/">SMK Open</a> project, supported by <a href="https://nordeafonden.dk/about-nordea-fonden">Nordea-fonden</a>. Briefly, the project aims to make the SMK collection digitally accessible, relevant, and useful to as many people as possible. Access comes in two parts: Human-readability and machine-readability. <em>Human-readability</em> means the website while <em>machine-readability</em> means our API, of which more in later posts. The website is the museum’s best attempt at a general, digital, visual interface to everything we have and as such it is a key component in our digital strategy.</p>

<h6 id="https-i-snap-as-eee8zvvm-webp-front-page-of-the-new-website" id="https-i-snap-as-eee8zvvm-webp-front-page-of-the-new-website"><img src="https://i.snap.as/EEe8ZVvM.webp" alt=""/>Front page of the new website</h6>

<p>This new wondrous thing is introduced in two stages. The first stage, launching now, rethinks SMK’s digital design (our visual identity has not been systematically digitized before) and our content. It divides SMK content into:</p>
<ul><li>Content pages (e.g. “The history of SMK”)</li>
<li>Exhibition pages</li>
<li>Events</li>
<li>Artworks</li>
<li>Staff members (which are content items and can therefore be used across other pages)</li></ul>

<p>Each content item is assigned a number of categories (defining the general topic, e.g. “Conservation”) and a number of tags (defining specifics, e.g. “Henri Matisse”). This taxonomy then helps us generate dynamic lists and collections of content across the site.</p>

<h6 id="https-i-snap-as-dcs8frun-webp-current-exhibitions-on-new-website-the-page-consists-of-automatically-generated-full-screen-links-to-other-pages" id="https-i-snap-as-dcs8frun-webp-current-exhibitions-on-new-website-the-page-consists-of-automatically-generated-full-screen-links-to-other-pages"><img src="https://i.snap.as/DCs8fRuN.webp" alt=""/>“Current exhibitions” on new website. The page consists of automatically generated full-screen links to other pages.</h6>

<p>In terms of process, defining a start date is always somewhat arbitrary. But actual planning started when we teamed up with digital agency <a href="https://1508.dk/">1508</a> almost exactly one year ago. Working from our quite flexible specifications, 1508 has provided UX, design and the actual development and led us through workshops and continuous demos and discussion. We have been heavily involved and have provided continuous feedback at almost every level.</p>

<p>One rare nearly set-in-stone decision was our choice of Wordpress as CMS. Although any choice of CMS comes with strings attached, we strongly feel that Wordpress is appropriate for us. While, our desire for complex use of content items across the site might seem to point to systems with more powerful data models, the accessibility of the Wordpress backend and the fact that it is virtually a Danish museum standard (meaning very little need for staff training) are much more important to us. Notably, though, our implementation is “<a href="https://pantheon.io/features/decoupled-cms">headless</a>”, meaning that we are using Wordpress more as a data repository than a front-end-generator.</p>

<h3 id="iiif-and-the-smk-taxonomy" id="iiif-and-the-smk-taxonomy"><strong>IIIF and the SMK taxonomy</strong></h3>

<p>The website does two things that are not immediately apparent, but that are important building blocks for our future work.</p>

<p>Firstly, it implements a connection to our asset management system, allowing us to implement a IIIF viewer for large reproductions of artworks. The <a href="https://iiif.io/">IIIF standard</a> is quickly becoming a popular way to display and share images across cultural institutions and we are quite thrilled to start down this path. For the user, it means the ability to zoom easily and quickly into artworks using the tiling logic, known from Google Maps, where you dynamically load only the part of the image that you need to see, and not the entire, enormous world map. For scholars, this also means the ability to display images from different institutions simultaneously for comparison and analysis.</p>

<h6 id="https-i-snap-as-4eoj7ysg-webp-iiif-viewer-showing-details-of-an-anna-ancher-painting" id="https-i-snap-as-4eoj7ysg-webp-iiif-viewer-showing-details-of-an-anna-ancher-painting"><img src="https://i.snap.as/4EOJ7ySG.webp" alt=""/>IIIF viewer showing details of an Anna Ancher painting.</h6>

<p>Secondly, Wordpress will function as our “taxonomy hub”. It will make the tag taxonomy available to other systems, thus allowing us to use it across all our platforms and thereby tie all our disparate content elements together. Ideally, when you see a piece of SMK content online in the future it will be automatically related to all other relevant pieces of content (videos, audio, research articles, images, blog entries…). This will be revolutionarily different from the current situation where finding those links can resemble detective work.</p>

<h2 id="level-one-completed-get-ready-for-level-two" id="level-one-completed-get-ready-for-level-two"><strong>Level one completed, get ready for level two</strong></h2>

<p>I mentioned that the website is stage one. Stage two (hopefully launching about a year from now) will present the collection in its full, interrelated, high-res glory. We are already hard at work figuring out how to best display everything — thankfully the <a href="https://blog.smk.dk/tag:musetech" class="hashtag"><span>#</span><span class="p-category">musetech</span></a> community has shared many inspiring thoughts over the years that we’ll greedily draw upon.</p>

<h2 id="get-in-touch" id="get-in-touch"><strong>Get in touch!</strong></h2>

<p>We heartily invite you to check out our new website. As you can imagine our list of bugs and ideas for improvement is already awe-inspiring, but we do genuinely welcome all sorts of feedback. In particular we’d love to know: Is this a place you feel like exploring (physically or digitally)? And how can we make everything even more inviting, interesting and useful for you. Thanks for clicking.</p>
]]></content:encoded>
      <guid>https://blog.smk.dk/finally-a-new-website-for-smk</guid>
      <pubDate>Wed, 15 Aug 2018 13:06:46 +0000</pubDate>
    </item>
    <item>
      <title>Everything Anywhere: Welcome to Your New Life as a Platform</title>
      <link>https://blog.smk.dk/everything-anywhere-welcome-to-your-new-life-as-a-platform?pk_campaign=rss-feed</link>
      <description>&lt;![CDATA[For open access, reductionism may be the way forward.&#xA;&#xA;!--more--&#xA;&#xA;The signs are all around us: Museums are abandoning the museum-as-building paradigm and even stepping beyond the museum-as-building+website “tiny addendum model” to embrace the idea of the museum as platform. Not in a coordinated rush, and certainly not at similar speeds but as an audible rumble fueled by the affordances of digital technologies.&#xA;&#xA;If I may very briefly summarize, the idea is this: The interface to our collections is now a myriad different views through a myriad different screens over which we have very little control. The museum, in other words, has become increasingly distributed (see also Bautista &amp; Balsamo, 2011) and strictly prioritizing one interface over another is non-trivial. Or as Nancy Proctor exemplarily notes “a bricks-and-mortar museum is an analog platform” (Proctor, 2010).&#xA;&#xA;Now, while this new model may be increasingly accepted in some variation it often remains largely metaphorical. While digitizing one’s collection, surrendering control, and making files accessible through third party platforms is brave, commendable, and challenging in itself it does not fulfil the digital potential of most museums. Let me explain why I believe we need to be more reductionist yet more disorganized in order to succeed.&#xA;&#xA;Towards a thick connection&#xA;&#xA;You may have accepted that the internet is the prime repository for shared knowledge (or ‘information’ if you insist) in our societies. For any knowledge institution we are long past the point where choosing not to have a strong impact online is the choice in need of an explanation.&#xA;&#xA;Many institutions have material online in some form and thus have at least some connection to the web. But the usefulness of these connections runs the gamut. A “thin” connection is one where very little material is published and/or where this material is unorganized. It’s what you get if you, say, place a collection of photos for download on your website. The very dedicated, the very knowledgable, or the very lucky can find them and use them but the downloaded photo will typically have very little associated information. Your museum may know a lot about the object but the user will be able to find out very little. In a sense, then, your collection will be connected to the shared knowledge bank though a very thin connection.&#xA;&#xA;At the other end of the spectrum, a “thick” connection is one where the museum’s knowledge resources are published far more systematically than the occasional JPG. It’s one where material is both accessible and useful to individuals and to systems. And it’s one where ideally all of the museum’s relevant knowledge comes packaged with the object. It’s also one that requires a leap into reductionism and disorder.&#xA;&#xA;The case for reductionism&#xA;&#xA;To the computer on your desk and the phone in your pocket, everything is data. Your device can run mind-numbing accounting software, play Handel’s Music for the Royal Fireworks, or display your flight schedule and in an important sense it will do it all equally well. It won’t care about specifics — it’s a platform, and a wildly important one due to rampant reductionism.&#xA;&#xA;Think of the standard shipping container (that probably contained your device at one point) — a similar mechanism. It’s context-free blandness is its very strength: It’s highly flexible and can pretty much contain everything.&#xA;&#xA;Don’t worry too much what’s inside as long as they stack well. Digital material is somewhat like a shipping container.&#xA;&#xA;Museums have digital content. But in order to make this content flexible enough to be truly useful we need to see not videos, research articles, blog entries, nor exhibition websites but content blocks. In a sense, then, we need to do what we are trained not to do: We need to ignore context.&#xA;&#xA;Does this sound disturbing? If so, the notion may have made you think of the disreputable practice of cross-platform publishing; the (often problematic) idea that the same content can work well in many different formats. But the reductionism we’re looking for here is not this, but rather that of a library: To be useful, a library defines any book as “simply” an instance of books, thus ignoring typography, quality of writing, the mental state of the author, the imagined reactions of the reader etc. But, emphatically, the library does not reformat books on purchase to look the same and museums have no good reason to do this either.&#xA;&#xA;In other words: We need to forget the properties of our materials that are irrelevant to organization without, of course, destroying these properties.&#xA;&#xA;Nicolai Abildgaard’s ‘The Wounded Philoctetes’ from 1775. Artwork placed by SMK in the public domain. Technically available but hard to find and use without specified relationships to other material.&#xA;&#xA;Order through disorder&#xA;&#xA;Which is the best way to organize our digital content blocks? If you’ve ever tried to draw up a sitemap for a complex website you know that this is dangerous territory. But in an important sense the answer is “in every way”. Organizing digital content is decidedly not the same as organizing physical objects. A physical object can be in one place at a time. In a physical art museum, you can organize your exhibition chronologically, by theme, by style, or by painter but you can only choose one. On the museum’s website, while you cannot have the physical artworks themselves, you can have all your representations and all your material in every way at once and this requires a footnote: We need to leave behind the shipping container metaphor — despite all their flexibility shipping containers can only be in one place at a time. Let’s refer to our material instead as elements.&#xA;&#xA;A sitemap has its uses but it’s a strangely physical exercise as it imposes a particular hierarchical structure on elements that really don’t need it and will necessarily correspond to the mental model of only very few users (on deeper levels it’s likely that no one user will find the structure fully logical). What we need is a way to let users choose their own structure based on their own definition of relevance. And for that, we need to establish connections between our elements by introducing what we could call associators. Associators are labels used to form relationships, in other words they are ‘metadata’.&#xA;&#xA;Of course, the more common name for such metadata is “tag” or even “keyword” but those may give the wrong impression as an associator is better thought of as anything that defines a relationship between elements. On this view, we can identify at least four types of associators:&#xA;&#xA;Organic. Keywords contributed by someone, whether museum staff or uses.&#xA;Machine-based. Keywords contributed by computer analysis of image content (for instance)&#xA;Found. Properties of the file itself such as camera metadata, document length, color distribution of an image.&#xA;Implied. Relations gleaned from user behaviour. For instance, a relationship can be established between two objects that are often seen by the same user.&#xA;&#xA;Using a scheme such as this, rich relationships can be built between objects in a collection. No all-encompassing authoritative taxonomy is needed. The price, of course, is a certain unpredictability. But the advantages are legion as you (and your users) will now have a much more versatile way of organizing everything based on any requirement.&#xA;&#xA;Towards thicker connections&#xA;&#xA;To successfully be a platform — in the very concrete and somewhat technical sense described here — museums must not just publish their material online but meaningfully connect their materials to each other and to the web. I’ve left out the technical specifications on purpose since the whole point here is to think beyond concrete platforms but in outline, it’s a model we’ll be pursuing at SMK — The National Gallery of Denmark as part of the SMK Open project in the years to come. The idea of the distributed museum is by no means new but if we can establish much more powerful “thick” connections between museums and the web we may just be pushing our relevance into a whole different league.&#xA;&#xA;This article appeared in Museum iD, issue 21 (August 2017)&#xA;&#xA;Bibliography&#xA;&#xA;Proctor, Nancy. “Digital: Museum As Platform, Curator As Champion, in the Age of Social Media.” Curator: The Museum Journal 53, no. 1 (2010): 35–43.&#xA;&#xA;Bautista, S, and Anne Balsamo. “Understanding the Distributed Museum: Mapping the Spaces of Museology in Contemporary Culture.” Museums and the Web 2011. 2011. http://www.museumsandtheweb.com/mw2011/papers/understandingthedistributedmuseummappingt.html.&#xA;&#xA;blockquote class=&#34;twitter-tweet&#34;p lang=&#34;en&#34; dir=&#34;ltr&#34;My presentation on a href=&#34;https://twitter.com/hashtag/openglam?src=hash&amp;amp;refsrc=twsrc%5Etfw&#34;#openglam/a, a href=&#34;https://twitter.com/smkmuseum?refsrc=twsrc%5Etfw&#34;@smkmuseum/a, and the possible future(s) of a href=&#34;https://twitter.com/hashtag/musetech?src=hash&amp;amp;refsrc=twsrc%5Etfw&#34;#musetech/a from a href=&#34;https://twitter.com/hashtag/museumideas?src=hash&amp;amp;refsrc=twsrc%5Etfw&#34;#museumideas/a today a href=&#34;https://t.co/0dDZhpcGwr&#34;https://t.co/0dDZhpcGwr/a/p&amp;mdash; Jonas Heide Smith (@jonassmith) a href=&#34;https://twitter.com/jonassmith/status/915922607635140608?refsrc=twsrc%5Etfw&#34;October 5, 2017/a/blockquote script async src=&#34;https://platform.twitter.com/widgets.js&#34; charset=&#34;utf-8&#34;/script]]&gt;</description>
      <content:encoded><![CDATA[<p><strong>For open access, reductionism may be the way forward.</strong></p>

<p><img src="https://i.snap.as/fnTZOpS1.webp" alt=""/></p>



<p>The signs are all around us: Museums are abandoning the <em>museum-as-building</em> paradigm and even stepping beyond the <em>museum-as-building+website</em> “tiny addendum model” to embrace the idea of the <em>museum as platform</em>. Not in a coordinated rush, and certainly not at similar speeds but as an audible rumble fueled by the affordances of digital technologies.</p>

<p>If I may very briefly summarize, the idea is this: The interface to our collections is now a myriad different views through a myriad different screens over which we have very little control. The museum, in other words, has become increasingly distributed (see also Bautista &amp; Balsamo, 2011) and strictly prioritizing one interface over another is non-trivial. Or as Nancy Proctor exemplarily notes “a bricks-and-mortar museum is an analog platform” (Proctor, 2010).</p>

<p>Now, while this new model may be increasingly accepted in some variation it often remains largely metaphorical. While digitizing one’s collection, surrendering control, and making files accessible through third party platforms is brave, commendable, and challenging in itself it does not fulfil the digital potential of most museums. Let me explain why I believe we need to be more reductionist yet more disorganized in order to succeed.</p>

<h2 id="towards-a-thick-connection" id="towards-a-thick-connection"><strong>Towards a thick connection</strong></h2>

<p>You may have accepted that the internet is the prime repository for shared knowledge (or ‘information’ if you insist) in our societies. For any knowledge institution we are long past the point where choosing <em>not</em> to have a strong impact online is the choice in need of an explanation.</p>

<p>Many institutions have material online in some form and thus have at least some connection to the web. But the usefulness of these connections runs the gamut. A “thin” connection is one where very little material is published and/or where this material is unorganized. It’s what you get if you, say, place a collection of photos for download on your website. The very dedicated, the very knowledgable, or the very lucky can find them and use them but the downloaded photo will typically have very little associated information. Your museum may know a lot about the object but the user will be able to find out very little. In a sense, then, your collection will be connected to the shared knowledge bank though a very thin connection.</p>

<p>At the other end of the spectrum, a “thick” connection is one where the museum’s knowledge resources are published far more systematically than the occasional JPG. It’s one where material is both accessible and useful to individuals and to systems. And it’s one where ideally all of the museum’s relevant knowledge comes packaged with the object. It’s also one that requires a leap into reductionism and disorder.</p>

<h2 id="the-case-for-reductionism" id="the-case-for-reductionism"><strong>The case for reductionism</strong></h2>

<p>To the computer on your desk and the phone in your pocket, everything is data. Your device can run mind-numbing accounting software, play Handel’s <em>Music for the Royal Fireworks</em>, or display your flight schedule and in an important sense it will do it all equally well. It won’t care about specifics — it’s a platform, and a wildly important one due to rampant reductionism.</p>

<p>Think of the standard shipping container (that probably contained your device at one point) — a similar mechanism. It’s context-free blandness is its very strength: It’s highly flexible and can pretty much contain everything.</p>

<p><img src="https://i.snap.as/tV6JZ2HO.webp" alt=""/></p>

<h6 id="don-t-worry-too-much-what-s-inside-as-long-as-they-stack-well-digital-material-is-somewhat-like-a-shipping-container" id="don-t-worry-too-much-what-s-inside-as-long-as-they-stack-well-digital-material-is-somewhat-like-a-shipping-container">Don’t worry too much what’s inside as long as they stack well. Digital material is somewhat like a shipping container.</h6>

<p>Museums have digital content. But in order to make this content flexible enough to be truly useful we need to see not videos, research articles, blog entries, nor exhibition websites but content blocks. In a sense, then, we need to do what we are trained not to do: We need to ignore context.</p>

<p>Does this sound disturbing? If so, the notion may have made you think of the disreputable practice of cross-platform publishing; the (often problematic) idea that the same content can work well in many different formats. But the reductionism we’re looking for here is not this, but rather that of a library: To be useful, a library defines any book as “simply” an instance of books, thus ignoring typography, quality of writing, the mental state of the author, the imagined reactions of the reader etc. But, emphatically, the library does <em>not</em> reformat books on purchase to look the same and museums have no good reason to do this either.</p>

<p>In other words: We need to forget the properties of our materials that are irrelevant to organization without, of course, destroying these properties.</p>

<h6 id="https-i-snap-as-prvoqjjx-webp-nicolai-abildgaard-s-the-wounded-philoctetes-from-1775-artwork-placed-by-smk-in-the-public-domain-technically-available-but-hard-to-find-and-use-without-specified-relationships-to-other-material" id="https-i-snap-as-prvoqjjx-webp-nicolai-abildgaard-s-the-wounded-philoctetes-from-1775-artwork-placed-by-smk-in-the-public-domain-technically-available-but-hard-to-find-and-use-without-specified-relationships-to-other-material"><img src="https://i.snap.as/PRvOqjJx.webp" alt=""/>Nicolai Abildgaard’s ‘The Wounded Philoctetes’ from 1775. Artwork placed by SMK in the public domain. Technically available but hard to find and use without specified relationships to other material.</h6>

<h2 id="order-through-disorder" id="order-through-disorder"><strong>Order through disorder</strong></h2>

<p>Which is the best way to organize our digital content blocks? If you’ve ever tried to draw up a sitemap for a complex website you know that this is dangerous territory. But in an important sense the answer is “in every way”. Organizing digital content is decidedly not the same as organizing physical objects. A physical object can be in one place at a time. In a physical art museum, you can organize your exhibition chronologically, by theme, by style, or by painter but you can only choose one. On the museum’s website, while you cannot have the physical artworks themselves, you can have all your representations and all your material in every way at once and this requires a footnote: We need to leave behind the shipping container metaphor — despite all their flexibility shipping containers can only be in one place at a time. Let’s refer to our material instead as <em>elements</em>.</p>

<p>A sitemap has its uses but it’s a strangely physical exercise as it imposes a particular hierarchical structure on elements that really don’t need it and will necessarily correspond to the mental model of only very few users (on deeper levels it’s likely that no one user will find the structure fully logical). What we need is a way to let users choose their own structure based on their own definition of relevance. And for that, we need to establish connections between our elements by introducing what we could call <em>associators</em>. Associators are labels used to form relationships, in other words they are ‘metadata’.</p>

<p>Of course, the more common name for such metadata is “tag” or even “keyword” but those may give the wrong impression as an associator is better thought of as anything that defines a relationship between elements. On this view, we can identify at least four types of associators:</p>
<ul><li><strong>Organic</strong>. Keywords contributed by someone, whether museum staff or uses.</li>
<li><strong>Machine-based</strong>. Keywords contributed by computer analysis of image content (for instance)</li>
<li><strong>Found</strong>. Properties of the file itself such as camera metadata, document length, color distribution of an image.</li>
<li><strong>Implied</strong>. Relations gleaned from user behaviour. For instance, a relationship can be established between two objects that are often seen by the same user.</li></ul>

<p>Using a scheme such as this, rich relationships can be built between objects in a collection. No all-encompassing authoritative taxonomy is needed. The price, of course, is a certain unpredictability. But the advantages are legion as you (and your users) will now have a much more versatile way of organizing everything based on any requirement.</p>

<h2 id="towards-thicker-connections" id="towards-thicker-connections"><strong>Towards thicker connections</strong></h2>

<p>To successfully be a platform — in the very concrete and somewhat technical sense described here — museums must not just publish their material online but meaningfully connect their materials to each other and to the web. I’ve left out the technical specifications on purpose since the whole point here is to think beyond concrete platforms but in outline, it’s a model we’ll be pursuing at SMK — The National Gallery of Denmark as part of the <a href="http://www.smk.dk/smkopen">SMK Open</a> project in the years to come. The idea of the distributed museum is by no means new but if we can establish much more powerful “thick” connections between museums and the web we may just be pushing our relevance into a whole different league.</p>

<p><em>This article appeared in Museum iD, issue 21 (August 2017)</em></p>

<h2 id="bibliography" id="bibliography"><strong>Bibliography</strong></h2>

<p>Proctor, Nancy. “Digital: Museum As Platform, Curator As Champion, in the Age of Social Media.” <em>Curator: The Museum Journal</em> 53, no. 1 (2010): 35–43.</p>

<p><em>Bautista, S, and Anne Balsamo. “Understanding the Distributed Museum: Mapping the Spaces of Museology in Contemporary Culture.” Museums and the Web 2011. 2011. &lt;<a href="http://www.museumsandtheweb.com/mw2011/papers/understanding">http://www.museumsandtheweb.com/mw2011/papers/understanding</a></em>the<em>distributed</em>museum<em>mapping</em>t.html.&gt;_</p>

<p><blockquote class="twitter-tweet"><p lang="en" dir="ltr">My presentation on <a href="https://twitter.com/hashtag/openglam?src=hash&amp;ref_src=twsrc%5Etfw"><a href="https://blog.smk.dk/tag:openglam" class="hashtag"><span>#</span><span class="p-category">openglam</span></a></a>, <a href="https://twitter.com/smkmuseum?ref_src=twsrc%5Etfw">@smkmuseum</a>, and the possible future(s) of <a href="https://twitter.com/hashtag/musetech?src=hash&amp;ref_src=twsrc%5Etfw"><a href="https://blog.smk.dk/tag:musetech" class="hashtag"><span>#</span><span class="p-category">musetech</span></a></a> from <a href="https://twitter.com/hashtag/museumideas?src=hash&amp;ref_src=twsrc%5Etfw"><a href="https://blog.smk.dk/tag:museumideas" class="hashtag"><span>#</span><span class="p-category">museumideas</span></a></a> today <a href="https://t.co/0dDZhpcGwr">https://t.co/0dDZhpcGwr</a></p>— Jonas Heide Smith (@jonassmith) <a href="https://twitter.com/jonassmith/status/915922607635140608?ref_src=twsrc%5Etfw">October 5, 2017</a></blockquote> </p>
]]></content:encoded>
      <guid>https://blog.smk.dk/everything-anywhere-welcome-to-your-new-life-as-a-platform</guid>
      <pubDate>Wed, 11 Oct 2017 09:10:16 +0000</pubDate>
    </item>
    <item>
      <title>Instant SMK art info? There’s an app for that</title>
      <link>https://blog.smk.dk/instant-smk-art-info-theres-an-app-for-that-f3m1?pk_campaign=rss-feed</link>
      <description>&lt;![CDATA[At SMK, we’d really really like to give guests easy, flexible access to information on the collection. We’d also really really like to avoid all the distractions of QR codes and dubious Bluetooth connections.&#xA;&#xA;!--more--&#xA;&#xA;With this in mind, we started collaborating with a group of Danish developers working on an app they call Vizgu (a combination of ‘visitor’ and ‘guide’ — not entirely sure about the z). Vizgu lets the visitor point his/her smartphone camera at an SMK painting and thus call up metadata, descriptive text and audio where available.&#xA;&#xA;This image recognition is made possible by storing all our photos of art in the Vizgu database. When the guest takes a picture of a piece, the app compares this photo to everything in the database and (almost always) finds the correct match in a matter of seconds.&#xA;&#xA;There are a few reasons why we — in all modesty — think this is a Highly Appropriate Solution(tm).&#xA;&#xA;Puts all processing where it belongs&#xA;&#xA;Giving guests easy access to information is a complex task — i.e. it involves complexity which can be delegated to different stages in the process.&#xA;&#xA;A code of some kind next to the artwork puts the complexity on the guest who has to (for instance) activate a QR reader (difficulty level: 8 out of 10, particularly for iPhone users) or type in a URL in the phone browser (difficulty level: 5, doable but not pleasant).&#xA;&#xA;Bluetooth transmitters like iBeacons is a way of relieving the guest of the hard work. It lets the room do the processing, if you will. Even assuming that the calibration works well, this solution involves telling the guest about Bluetooth in some form (you, clever reader, surely know all about Bluetooth but think about the rest of your family). This solution also involves a somewhat complicated hardware setup that needs to be maintained by museum staff (also on weekends, especially on weekends) — and upgraded from time to time = $$$.&#xA;&#xA;Point the camera at a painting and press the screen for info — nice and simple.&#xA;&#xA;The Vizgu solution, on the other hand, leaves the heavy lifting to a high-powered computer (i.e. your phone) and you don’t have to know anything about Bluetooth, browsers, or databases to use it.&#xA;&#xA;Uses well-known interaction paradigm&#xA;&#xA;… which is just to say that telling guests to simply use their camera is UX heaven. Mostly everybody knows how to point and shoot. You have to find and install the app (a barrier in itself, to be sure) but after that things are as simple as they can probably be.&#xA;&#xA;Uses a non-rival form of interaction&#xA;&#xA;Using Vizgu does not compromise any other type of art appreciation. No mounted screens, no (potentially) ugly codes or beacons — in short, nothing do detract from traditional ways of using the museum. Best of both worlds.&#xA;&#xA;Rhymes well with our strategy&#xA;&#xA;We are museum people with very limited developer resources. Building, maintaining and constantly updating even one app (let alone one for several platforms) would instantly drain our resources. It would not be a good use of our time.&#xA;&#xA;Shoot now, read later? The “History” tab saves the art you’ve selected and you can do the reading somewhere comfortable, e.g. your couch at home.&#xA;&#xA;But more importantly, our strategy (most obvious in the SMK Open project) is to spend our time making SMK work as a platform. This involves making all of our data/content as flexibly available as possible — for others to use, share, and build upon. We do not want to be app developers, we want to be providers of data, content, and knowledge. We want to enable anyone with a good idea to use any portion of our data to enrich their website, app, or service.&#xA;&#xA;In this way, we arguably outsource the development and maintenance of SMK-related services freeing us to work on the quality of the data itself. Sure, this also means outsourcing the user-experience and a loss of control over context and presentation. But we still have full control over what to recommend to our guests and happily observe that external developers tend to welcome our suggestions.&#xA;&#xA;This has certainly been the case with Vizgu whom we’ve been more than thrilled to work with. We look forward to formally launching the app in September 2017, and you, dear reader, are more than welcome to join us (link to Facebook).&#xA;&#xA;blockquote class=&#34;twitter-tweet&#34;p lang=&#34;en&#34; dir=&#34;ltr&#34;Our new a href=&#34;https://twitter.com/smkmuseum?refsrc=twsrc%5Etfw&#34;@smkmuseum/a image recognition app is nearly ready. I&amp;#39;ve blogged some thoughts. a href=&#34;https://twitter.com/hashtag/smkmuseum?src=hash&amp;amp;refsrc=twsrc%5Etfw&#34;#smkmuseum/a a href=&#34;https://twitter.com/hashtag/musesocial?src=hash&amp;amp;refsrc=twsrc%5Etfw&#34;#musesocial/a a href=&#34;https://t.co/UFddPy4B2Y&#34;https://t.co/UFddPy4B2Y/a/p&amp;mdash; Jonas Heide Smith (@jonassmith) a href=&#34;https://twitter.com/jonassmith/status/894458349286248449?refsrc=twsrc%5Etfw&#34;August 7, 2017/a/blockquote script async src=&#34;https://platform.twitter.com/widgets.js&#34; charset=&#34;utf-8&#34;/script&#xA;&#xA;blockquote class=&#34;twitter-tweet&#34;p lang=&#34;en&#34; dir=&#34;ltr&#34;Our app-in-the-making recognizes a href=&#34;https://twitter.com/smkmuseum?refsrc=twsrc%5Etfw&#34;@smkmuseum/a art and brings up info + audio (where available). No QR, no Bluetooth 🕺 a href=&#34;https://twitter.com/hashtag/musetech?src=hash&amp;amp;refsrc=twsrc%5Etfw&#34;#musetech/a a href=&#34;https://twitter.com/hashtag/smkmuseum?src=hash&amp;amp;refsrc=twsrc%5Etfw&#34;#smkmuseum/a a href=&#34;https://t.co/WoxnpF3qDh&#34;pic.twitter.com/WoxnpF3qDh/a/p&amp;mdash; Jonas Heide Smith (@jonassmith) a href=&#34;https://twitter.com/jonassmith/status/893055118475759616?ref_src=twsrc%5Etfw&#34;August 3, 2017/a/blockquote script async src=&#34;https://platform.twitter.com/widgets.js&#34; charset=&#34;utf-8&#34;/script]]&gt;</description>
      <content:encoded><![CDATA[<p><strong>At SMK, we’d really really like to give guests easy, flexible access to information on the collection. We’d also really really like to avoid all the distractions of QR codes and dubious Bluetooth connections.</strong></p>

<p><img src="https://i.snap.as/0ysSCEUw.webp" alt=""/></p>



<p>With this in mind, we started collaborating with a group of Danish developers working on an app they call <em><a href="http://www.vizgu.com/">Vizgu</a></em> (a combination of ‘visitor’ and ‘guide’ — not entirely sure about the z). <em>Vizgu</em> lets the visitor point his/her smartphone camera at an SMK painting and thus call up metadata, descriptive text and audio where available.</p>

<p>This image recognition is made possible by storing all our photos of art in the <em>Vizgu</em> database. When the guest takes a picture of a piece, the app compares this photo to everything in the database and (almost always) finds the correct match in a matter of seconds.</p>

<p>There are a few reasons why we — in all modesty — think this is a Highly Appropriate Solution™.</p>

<h2 id="puts-all-processing-where-it-belongs" id="puts-all-processing-where-it-belongs"><strong>Puts all processing where it belongs</strong></h2>

<p>Giving guests easy access to information is a complex task — i.e. it involves complexity which can be delegated to different stages in the process.</p>

<p>A code of some kind next to the artwork puts the complexity on the guest who has to (for instance) activate a QR reader (difficulty level: 8 out of 10, particularly for iPhone users) or type in a URL in the phone browser (difficulty level: 5, doable but not pleasant).</p>

<p>Bluetooth transmitters like <a href="https://en.wikipedia.org/wiki/IBeacon">iBeacons</a> is a way of relieving the guest of the hard work. It lets the room do the processing, if you will. Even assuming that the calibration works well, this solution involves telling the guest about Bluetooth in some form (you, clever reader, surely know all about Bluetooth but think about the rest of your family). This solution also involves a somewhat complicated hardware setup that needs to be maintained by museum staff (also on weekends, <em>especially</em> on weekends) — and upgraded from time to time = $$$.</p>

<h6 id="https-i-snap-as-ubhcqf3j-webp" id="https-i-snap-as-ubhcqf3j-webp"><img src="https://i.snap.as/ubHCqf3J.webp" alt=""/></h6>

<h6 id="point-the-camera-at-a-painting-and-press-the-screen-for-info-nice-and-simple" id="point-the-camera-at-a-painting-and-press-the-screen-for-info-nice-and-simple">Point the camera at a painting and press the screen for info — nice and simple.</h6>

<p>The <em>Vizgu</em> solution, on the other hand, leaves the heavy lifting to a high-powered computer (i.e. your phone) and you don’t have to know anything about Bluetooth, browsers, or databases to use it.</p>

<h3 id="uses-well-known-interaction-paradigm" id="uses-well-known-interaction-paradigm"><strong>Uses well-known interaction paradigm</strong></h3>

<p>… which is just to say that telling guests to simply use their camera is UX heaven. Mostly <em>everybody</em> knows how to point and shoot. You have to find and install the app (a barrier in itself, to be sure) but after that things are as simple as they can probably be.</p>

<h3 id="uses-a-non-rival-form-of-interaction" id="uses-a-non-rival-form-of-interaction"><strong>Uses a non-rival form of interaction</strong></h3>

<p>Using <em>Vizgu</em> does not compromise any other type of art appreciation. No mounted screens, no (potentially) ugly codes or beacons — in short, nothing do detract from traditional ways of using the museum. Best of both worlds.</p>

<h3 id="rhymes-well-with-our-strategy" id="rhymes-well-with-our-strategy"><strong>Rhymes well with our strategy</strong></h3>

<p>We are museum people with very limited developer resources. Building, maintaining and constantly updating even one app (let alone one for several platforms) would instantly drain our resources. It would not be a good use of our time.</p>

<p><img src="https://i.snap.as/VBabsnz6.webp" alt=""/></p>

<h6 id="shoot-now-read-later-the-history-tab-saves-the-art-you-ve-selected-and-you-can-do-the-reading-somewhere-comfortable-e-g-your-couch-at-home" id="shoot-now-read-later-the-history-tab-saves-the-art-you-ve-selected-and-you-can-do-the-reading-somewhere-comfortable-e-g-your-couch-at-home">Shoot now, read later? The “History” tab saves the art you’ve selected and you can do the reading somewhere comfortable, e.g. your couch at home.</h6>

<p>But more importantly, our strategy (most obvious in the <em><a href="http://www.smk.dk/en/about-smk/camp00/">SMK Open</a></em> project) is to spend our time making SMK work as a platform. This involves making all of our data/content as flexibly available as possible — for others to use, share, and build upon. We do not <em>want</em> to be app developers, we want to be providers of data, content, and knowledge. We want to enable anyone with a good idea to use any portion of our data to enrich their website, app, or service.</p>

<p>In this way, we arguably outsource the development and maintenance of SMK-related services freeing us to work on the quality of the data itself. Sure, this also means outsourcing the user-experience and a loss of control over context and presentation. But we still have full control over what to recommend to our guests and happily observe that external developers tend to welcome our suggestions.</p>

<p>This has certainly been the case with <em>Vizgu</em> whom we’ve been more than thrilled to work with. We look forward to formally launching the app in September 2017, and you, dear reader, are more than welcome to <a href="https://www.facebook.com/events/159699671261332/?acontext=%7B%22ref%22%3A%224%22%2C%22feed_story_type%22%3A%22370%22%2C%22action_history%22%3A%22null%22%7D">join us</a> (link to Facebook).</p>

<p><blockquote class="twitter-tweet"><p lang="en" dir="ltr">Our new <a href="https://twitter.com/smkmuseum?ref_src=twsrc%5Etfw">@smkmuseum</a> image recognition app is nearly ready. I&#39;ve blogged some thoughts. <a href="https://twitter.com/hashtag/smkmuseum?src=hash&amp;ref_src=twsrc%5Etfw"><a href="https://blog.smk.dk/tag:smkmuseum" class="hashtag"><span>#</span><span class="p-category">smkmuseum</span></a></a> <a href="https://twitter.com/hashtag/musesocial?src=hash&amp;ref_src=twsrc%5Etfw"><a href="https://blog.smk.dk/tag:musesocial" class="hashtag"><span>#</span><span class="p-category">musesocial</span></a></a> <a href="https://t.co/UFddPy4B2Y">https://t.co/UFddPy4B2Y</a></p>— Jonas Heide Smith (@jonassmith) <a href="https://twitter.com/jonassmith/status/894458349286248449?ref_src=twsrc%5Etfw">August 7, 2017</a></blockquote> </p>

<p><blockquote class="twitter-tweet"><p lang="en" dir="ltr">Our app-in-the-making recognizes <a href="https://twitter.com/smkmuseum?ref_src=twsrc%5Etfw">@smkmuseum</a> art and brings up info + audio (where available). No QR, no Bluetooth 🕺 <a href="https://twitter.com/hashtag/musetech?src=hash&amp;ref_src=twsrc%5Etfw"><a href="https://blog.smk.dk/tag:musetech" class="hashtag"><span>#</span><span class="p-category">musetech</span></a></a> <a href="https://twitter.com/hashtag/smkmuseum?src=hash&amp;ref_src=twsrc%5Etfw"><a href="https://blog.smk.dk/tag:smkmuseum" class="hashtag"><span>#</span><span class="p-category">smkmuseum</span></a></a> <a href="https://t.co/WoxnpF3qDh">pic.twitter.com/WoxnpF3qDh</a></p>— Jonas Heide Smith (@jonassmith) <a href="https://twitter.com/jonassmith/status/893055118475759616?ref_src=twsrc%5Etfw">August 3, 2017</a></blockquote> </p>
]]></content:encoded>
      <guid>https://blog.smk.dk/instant-smk-art-info-theres-an-app-for-that-f3m1</guid>
      <pubDate>Fri, 04 Aug 2017 08:55:24 +0000</pubDate>
    </item>
  </channel>
</rss>