LiU-ITN-TEK-G-13/009-SE Utveckling av ett verktyg för produktkataloggenerering Jenny Fritz 2013-04-19 Department of Science and Technology Linköping University SE-601 74 Norrköping, Sweden Institutionen för teknik och naturvetenskap Linköpings universitet 601 74 Norrköping LiU-ITN-TEK-G-13/009-SE Utveckling av ett verktyg för produktkataloggenerering Examensarbete utfört i Tekniska informationssystem vid Tekniska högskolan vid Linköpings universitet Jenny Fritz Handledare Stefan Gustavson Handledare Daniel Berglund Examinator Jan Petersson Norrköping 2013-04-19 Upphovsrätt Detta dokument hålls tillgängligt på Internet eller dess framtida ersättare under en längre tid från publiceringsdatum under förutsättning att inga extraordinära omständigheter uppstår. Tillgång till dokumentet innebär tillstånd för var och en att läsa, ladda ner, skriva ut enstaka kopior för enskilt bruk och att använda det oförändrat för ickekommersiell forskning och för undervisning. Överföring av upphovsrätten vid en senare tidpunkt kan inte upphäva detta tillstånd. All annan användning av dokumentet kräver upphovsmannens medgivande. För att garantera äktheten, säkerheten och tillgängligheten finns det lösningar av teknisk och administrativ art. Upphovsmannens ideella rätt innefattar rätt att bli nämnd som upphovsman i den omfattning som god sed kräver vid användning av dokumentet på ovan beskrivna sätt samt skydd mot att dokumentet ändras eller presenteras i sådan form eller i sådant sammanhang som är kränkande för upphovsmannens litterära eller konstnärliga anseende eller egenart. För ytterligare information om Linköping University Electronic Press se förlagets hemsida http://www.ep.liu.se/ Copyright The publishers will keep this document online on the Internet - or its possible replacement - for a considerable time from the date of publication barring exceptional circumstances. The online availability of the document implies a permanent permission for anyone to read, to download, to print out single copies for your own use and to use it unchanged for any non-commercial research and educational purpose. Subsequent transfers of copyright cannot revoke this permission. All other uses of the document are conditional on the consent of the copyright owner. The publisher has taken technical and administrative measures to assure authenticity, security and accessibility. According to intellectual property law the author has the right to be mentioned when his/her work is accessed as described above and to be protected against infringement. For additional information about the Linköping University Electronic Press and its procedures for publication and for assurance of document integrity, please refer to its WWW home page: http://www.ep.liu.se/ Jenny Fritz Abstract Today, product catalogs are published and distributed by a large share of retail companies. However, the process of catalog production can be both time consuming and resource heavy. The purpose of this thesis has been to find a solution to that problem. This was done by researching different needs and demands regarding catalog production which was then followed by implementation of a software tool that could accomodate those needs. The goal was to automatically produce a product catalog in PDF format out of an existing product database. A pilot study showed that despite differences in existing catalog layouts, there still are some common elements such as product image and price. This was used as a basis during the implementation in which it was assumed that a product database, no matter the type of data source, always contains specific information elements to be published. To allow for different layouts of a product catalog, a separate template handler was implemented. The purpose of this was to give the user an opportunity to configure for instance text field placements, image dimensions and which background images to use - all in favor of individual needs and oppinions. To reach the goals the scope of the project was extended and during spring 2013 it was finalized with the desired functionalities. Despite this, a whole lot of possibilities regarding further development can be seen, especially since the need of a more efficient process of catalog production seems to exist. Sammanfattning Produktkataloger publiceras och distribueras idag av många detaljhandelsföretag, stora som små. Dock har det påvisats att katalogproduktion kan vara både tids- och resurskrävande. Detta examensarbete har därför syftat till att finna en lösning på problemet genom att undersöka behov och förutsättningar och därpå utveckla ett verktyg som kan underlätta arbetet med att skapa produktkataloger. Målsättningen var att det resulterande verktyget per automatik skulle framställa en produktkatalog i PDF-format utifrån ett befintligt artikelregister. En förstudie visade att trots olikheter i befintliga produktkatalogers utformning finns ändå vissa gemensamma element såsom produktbild och pris. Detta faktum utnyttjades vid utvecklingsarbetet där det förutsattes att ett artikelregister, oavsett typ av datakälla, alltid innehåller vissa informationselement som kan publiceras. För att sedan ge utrymme för olikheter i den grafiska utformningen av en katalog implementerades en separat mallhantering. Syftet med detta var att ge användaren möjligheten att justera exempelvis placering av textfält, bilddimensioner och bakgrundsbilder efter eget behov och tycke. För att komma i hamn tilläts projektet att växa i omfattning och under våren 2013 fungerade kataloggenereringsverktyget i enlighet med de mål som satts upp. Trots detta ses fortfarande stora möjligheter för vidareutveckling, särskilt som behovet av effektiviserad katalogproduktion tycks stort. i Förord Det här projektet har varit en stor personlig utmaning för mig och jag skulle inte ha lyckats genomföra det om det inte vore för personerna i min närhet som stöttat och drivit på mig. Jag vill först och främst tacka Kerstin och Kåwe Agentur. Det var tack vare denna kontakt som jag fick idén till projektet från första början och den fria tillgången till Kåwe:s artikelregister gav mig något att utgå ifrån. Tack till min familj och mina vänner som försiktigt manat på mig och försökt uppmuntra mig när det varit jobbigt. Till sist vill jag tacka min handledare Daniel Berglund som fått jobba minst lika hårt som mig för att ro detta projekt i hamn. Tack för tekniskt stöd, hjälp att tänka och framför allt för ett till synes oändligt tålamod. Nu är det äntligen över... iii Innehåll 1 2 3 Inledning 1.1 Bakgrund . . . . . . . . . 1.2 Syfte . . . . . . . . . . . . 1.3 Avgränsningar . . . . . . . 1.4 Mål . . . . . . . . . . . . 1.5 Metod . . . . . . . . . . . 1.5.1 PPS . . . . . . . . 1.5.2 Utvecklingsmetod 1.6 Disposition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Förstudie 2.1 Kravspecifikation . . . . . . . . . . . . . 2.2 Produktkataloger . . . . . . . . . . . . . 2.2.1 Produktkatalogen som företeelse . 2.2.2 Innehålls- och layoutkonventioner 2.3 Behovsanalys . . . . . . . . . . . . . . . 2.4 Befintliga verktyg och tjänster . . . . . . 2.4.1 Layoutprogram . . . . . . . . . . 2.4.2 Katalogproduktion . . . . . . . . 2.4.3 Slutsats . . . . . . . . . . . . . . 2.5 Mjukvara . . . . . . . . . . . . . . . . . 2.5.1 Kort om Excel . . . . . . . . . . 2.5.2 PDF . . . . . . . . . . . . . . . . 2.5.3 Javabiblioteket iText . . . . . . . 2.5.4 Excel-import i Java . . . . . . . . 2.5.5 XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1 1 2 2 2 2 3 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 5 5 5 6 10 12 12 12 16 16 16 17 20 21 22 Utveckling 3.1 Utvecklingsmiljö . . . . . . . . . . . . . . . . 3.2 Grafisk design . . . . . . . . . . . . . . . . . . 3.2.1 Övergripande kataloglayout och design 3.2.2 Artikellayout . . . . . . . . . . . . . . 3.2.3 Övrig layout . . . . . . . . . . . . . . 3.2.4 Grafiskt material . . . . . . . . . . . . 3.3 Programutveckling . . . . . . . . . . . . . . . 3.3.1 Verktygets funktionaliteter . . . . . . . 3.3.2 Implementering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 25 26 26 26 29 29 30 30 31 v . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vi Innehåll 4 Resultat och diskussion 41 4.1 Utvärdering av verktyget . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 4.2 Resultat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 4.3 Vidareutveckling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 Litteraturförteckning 45 Bilaga 1 Kravspeci kation 47 Figurer 1.1 Arbetsprocess . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8 Färgkodning i innehållsförteckning och i sidhuvud, exempel ur Biltemas katalog 2012/13 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Uppslag ur Biltemas katalog Höst/Vinter 2012/13 . . . . . . . . . . . . . . . Uppslag ur Nevotex katalog 2012-2013 . . . . . . . . . . . . . . . . . . . . EasyCatalog i InDesign . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Kataloggenerering i CMS-systemet Magento . . . . . . . . . . . . . . . . . Sektionerna i en PDF-fil . . . . . . . . . . . . . . . . . . . . . . . . . . . . iText exempel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XML exempel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 8 9 14 15 19 21 23 3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8 3.9 3.10 3.11 3.12 3.13 Layout för artikel . . . . . . . . . . . . . . . . . . . . . . . . . Gruppering av liknande artiklar . . . . . . . . . . . . . . . . . . En artikel - flera bilder . . . . . . . . . . . . . . . . . . . . . . Fullständig sido-layout . . . . . . . . . . . . . . . . . . . . . . Layout för innehållsförteckning . . . . . . . . . . . . . . . . . Layout för titelsida till kapitel . . . . . . . . . . . . . . . . . . Programflöde . . . . . . . . . . . . . . . . . . . . . . . . . . . Utdrag ur artikelregistret . . . . . . . . . . . . . . . . . . . . . XML-dokumentets strukturprincip . . . . . . . . . . . . . . . . Flödesschema över katalogexport . . . . . . . . . . . . . . . . . Flödesschema över generering och infogande av artikeldokument Dialogruta vid fel sökväg till artikelregister . . . . . . . . . . . Dialogruta då katalogfil redan existerar . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 28 28 29 30 30 30 32 33 35 37 38 38 vii . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 Ordlista .ps Filformatet för PostScript. .xls Filformat för dokument skapade i MS Excel. .xlsx XML-baserat filformat för dokument skapade i MS Excel. Adobe Acrobat Kommersiellt datorprogram för att skapa och editera PDF-dokument. Adobe Reader Fritt datorprogram för att visa PDF-dokument. AOT Ahead-Of-Time kompilator. Kompilerar exempelvis Java-kod till maskinkod för en specifik plattform. Apache PDFBox Öppet Java-bibliotek för att arbeta med PDF-filer. Apache POI Apache Poor Obfuscation Implementation. Fritt Java API för att hantera digitala dokument. API Application Programming Interface ASP.NET Programspråk för att skapa dynamiskt webb-innehåll. BFO Syftar till Big Faceless Java PDF Library, ett öppet Java-bibliotek skapat av BFO. CMS Content Management System. Webbaserat innehållshanteringssystem för elektronisk publicering. CMYK Färgmodell för fyrfärgstryck. Dictionary Objektstyp som beskriver innehållsobjekt i en PDF-fil. DOM Document Object Model. Konvention för trädstrukturerat dokumentinnehåll. Drupal Öppet blogg- och innehållshanteringssystem. DTD Document Type Definition. Dokumentmall för XML-filer. DTP DeskTop Publishing. Datorstödd layout av trycksaker. EasyCatalog Plug-in modul till InDesign för databaskoppling och katalogproduktion. ix x Ordlista Eclipse Utvecklingsmiljö för Java-applikationer. F/OSS Free and Open Source Software GiBi sPrint Plug-in modul till Joomla för att skapa produktkataloger. GIF Bildformatsstandard för icke-destruktiv komprimering. GNU GPL GNU General Public License. Upphovsrättslicens för fri programvara. GNU LGPL GNU Lesser General Public License. Upphovsrättslicens för fri programvara utan distribution av tillhörande källkod. HSSF Horrible SpreadSheet Format. Java-bibliotek inom Apache POI för att skapa och läsa .xls-filer. Illustrator Illustrationsprogram utvecklat av Adobe. InDesign Program för desktop publishing utvecklat av Adobe Systems. ISO Internationella StandardiseringsOrganisationen iText Öppet Java-bibliotek för att arbete med PDF-filer. JAR Java ARchive JAXP Java API for XML Processing. Fritt Java-bibliotek för XMLhantering. JDK Java Development Kit JDOM Fritt Java-bibliotek för XML-hantering. JExcel Fritt Java API för att hantera Excel-dokument. Joomla Öppet innehållshanteringssystem JPEG Bildformatsstandard för destruktiv komprimering. Lämpligt för lagring av fotografier. Litium Studio Kommersiellt innehållshanteringssystem utvecklat av Microsoft. Magento Kommersiell webbapplikation för e-handel utvecklat av Varien. MS Access Databashanteringssystem utvecklat av Microsoft. MS Publisher Program för desktop publishing utvecklat av Microsoft. MySQL Databashanteringssystem som använder sig av frågespråket SQL. ODBC Open DataBase Connectivity. Standardiserad åtkomstmetod för databaser. Ordlista xi OLE2 Objekt Linking and Embedding Compound Document. Standard för dokumentformat skapade av Microsoft. OOXML Office Open XML. Standard för dokumentformat. Oracle Database Databashanteringssystem utvecklat av Oracle Corporation. osCommerce Öppet webbutikssystem. PDF Portable Document Format. Standardiserat dokumentformat skapat av Adobe Systems. PDF Catalog Creator Modul till osCommerce för att skapa produktkataloger. PDF/A Delmängd av PDF-standarden som särskilt berör bevarande av dokument. PDF/X Delmängd av PDF-standarden som särskilt berör grafiskt utbyte inom exempelvis tryckeribranschen. PHP Hypertext PreProcessor. Skriptspråk för att skapa dynamiskt webbinnehåll. PNG Bildformat lämpligt för lagring av icke-fotografiska bilder. PostScript Programspråk för att beskriva utseendet på sidor i digitala dokument. PPS Praktisk ProjektStyrning. Projektstyrningsmodell framtagen av TietoEnator. QuarkXPress Program för desktop publishing utvecklat av Quark. RIP Raster Imaging Processor. Del i utskriftssystem som konverterar text och bild till ett rastermönster. SAX Simple API for XML SQL Structured Query Language. Frågespråk för databashantering. StAX Streaming API for XML SVN Subversion. Versionshanteringssystem. TIFF Bildformat för bitmapsuppbyggda bilder. VirtueMart Catalog Plug-in modul till Joomla för att skapa produktkataloger. Visma Administration Vanligt förekommande ekonomisystem. Wordpress Öppet blogg- och innehållshanteringssystem. WYSIWYG What You See Is What You Get. Gränssnitt som återger slutresultatet då dokument och innehåll skapas. XML EXtensible Markup Language xii Ordlista XML Namespace Specifikation av namnrymden i en XML-fil. XML schema Deklarerar egenskaper och regler för en XML-fil. XPath Frågespråk för hantering av XML-filer. XSLT Märkspråk för att transformera XML-dokument. XSSF XML SpreadSheet Format. Java-bibliotek inom Apache POI för att skapa och läsa .xlsx-filer. Kapitel 1 Inledning Denna rapport är resultatet av ett examensarbete utfört på Institutionen för Teknik och Naturvetenskap vid Linköpings Universitet inom högskoleingenjörsutbildningen Medie- och Kommunikationsteknik. Rapporten utreder problematiken kring att implementera ett verktyg som automatisk framställer produktkataloger. 1.1 Bakgrund Det enskilt viktigaste som företagare inom detaljhandeln är att visa och marknadsföra sitt produktsortiment för potentiella kunder. Många företag utnyttjar idag Internet och e-handel för detta ändamål. Trots detta är den mer traditionella tryckta produktkatalogen ett utmärkt sätt att nå ut till kunder, vilket fortfarande utnyttjas inom de flesta branscher. Detta kan särskilt sägas för de mer traditionsbundna branscherna, samt där det inte finns benägenhet att ligga i den tekniska utvecklingens framkant. Som småföretagare kan det dock innebära att det saknas både tid och tillräcklig kunskap inom nödvändig mjukvaruhantering för att kunna framställa en produktkatalog från grunden. Alternativet att leja ut uppdraget kan istället innebära en större kostnad som inte kan motiveras företagsekonomiskt. Utöver föregående problem finns alltid risken att infoga felaktig information vid manuell framställning av en produktkatalog. Möjligheten att kunna använda ett enkelt mjukvaruverktyg som automatiskt framställer en produktkatalog från ett befintligt artikelregister skulle potentiellt kunna avhjälpa problemen ovan, samt underlätta vid uppdateringar av materialet. Idén till projektet uppkom från observationer av arbetet hos textilgrossistföretaget Kåwe Agentur AB som flera gånger per år skickar ut uppdaterade tryckta produktkataloger till sina kunder. Därför används företaget som fallstudie i syfte att utreda behov under förstudien samt för att samla in artikeldata vilket ska användas vid tester av det resulterande verktyget. 1.2 Syfte Syftet med examensarbetet är att genomföra en behovsanalys och teknikstudie kring hur ett verktyg för att automatiskt generera produktkataloger kan utformas. Med utgångspunkt ur slutsatser och resultat i denna förstudie ska sedan ett kataloggenereringsverktyg implementeras som uppfyller kraven i en på förhand framtagen kravspecifikation vilken återfinns i bilaga 1. 1 2 Inledning Under utvecklingen ska befintlig kunskap och teknik inom grafisk design och mjukvaruutveckling tillämpas. Problematiseringen består i huvudsak av följande: Hur den grafiska katalogdesignen kan generaliseras och på så vis vara applicerbar på artiklar och produkter, oavsett produkttyp och/eller omfattning av produktsortiment. Hur den grafiska katalogdesignen kan realiseras med hjälp av befintliga programbibliotek samt hur nödvändigt data smidigast läses in i det resulterande verktyget. Syftet med det färdiga verktyget är främst resursbesparingar samt att minska mängden felaktig information i det färdiga materialet. 1.3 Avgränsningar Utveckling av ett grafiskt användargränssnitt till verktyget skulle innebära att projektet även omfattade design och tester för att optimera användarvänligheten vid interaktion. Då detta bedöms som alltför omfattande för att rymmas inom examensarbetets tidsramar kommer endast ett enklare gränssnitt utvecklas som fullgott uppfyller användningskraven i kravspecifikationen. Det innebär även att användare av verktyget får ett begränsat inflytande över produktkatalogens disposition och layout vid interaktion. Eftersom projektet erbjuder en mängd utvecklingsmöjligheter får kravspecifikationen även i övrigt sätta ramarna för vilken funktionalitet som ska utvecklas inom examensarbetet. Vidareutveckling diskuteras i kapitel 4 - Resultat och diskussion. 1.4 Mål Examensarbetet är avsett att resultera i ett enkelt och generellt verktyg för automatisk generering av produktkataloger. Målet är nått när framtagen kravspecifikation uppfylls. 1.5 1.5.1 Metod PPS För att styra och planera genomförandet används PPS (Praktisk ProjektStyrning)1 som metod. PPS bygger på att förbereda projektet väl genom att sätta upp tydliga mål och synliggöra risker samt under projektets gång kontinuerligt stämma av progressen. Inför examensarbetet har en projektplan tagits fram som bland annat beskriver idé och mål, tidplan och milstolpar, projektets organisation och arbetsformer samt de risker som bedöms kunna uppstå under projektets gång. Exempel på det senare kan vara att tidplanen förskjuts och vilka åtgärder som krävs för att förebygga detta. Under examensarbetets gång ska kontinuerliga möten hållas med den externa handledaren för projektet där avstämning görs över det tillryggalagda arbetet samt över arbetsplan för kommande period. Syftet är att driva projektet framåt och i rätt riktning. 1 Projektstyrningsmodell framtagen av TietoEnator 1.6 Disposition 1.5.2 3 Utvecklingsmetod Utvecklingsmetoden har utgått från vattenfallsmodellen vilken grundar sig i stegvis utveckling. Arbetsprocessen beskrivs i figur 1.1. Figur 1.1. Arbetsprocess Under förstudiefasen genomfördes en teknikstudie och behovsanalys. För att skaffa kunskap inom relevant teknik utforskades till största delen online-resurser. Behovsanalysen baserades på observationer vid Kåwe Agentur AB samt analyser av aktuella produktkataloger. Även befintliga verktyg och tjänster för automatisk generering av elektroniska dokument utforskades. Vid arbetet med den grafiska designen togs en preliminär grafisk layout för en produktkatalog fram. Under implementationsfasen modifierades och fastställdes den grafiska layouten utefter de möjligheter och begränsningar som gavs. Programutvecklingen skedde i en iterativ process. Ett första grovt utkast till verktyget skapades vilket realiserade den grafiska design som tagits fram. På så vis synliggjordes en del av de dataformat och programfunktioner som behövde implementeras vid arbetet med dataimport till verktyget. Då import och export realiserats förfinades och optimerades programmets funktionalitet. För att uppnå projektets mål genomfördes till sist ett funktionstest utformat så att varje krav i kravspecifikationen kunde verifieras som uppfyllt. 1.6 Disposition Rapporten är uppdelad i tre huvudkapitel: Förstudie, Utveckling samt Resultat och diskussion. I Förstudie-kapitlet beskrivs resultatet av behovsanalysen och teknikstudien. Som inledning förklaras den kravspecifikation som är ramsättande för projektet. Därefter lämnas en redogörelse över konventioner som gäller för utformningen av produktkataloger i dagsläget. Detta följs av en behovsanalys där behovet av en effektivisering vid katalogproduktion klargörs 4 Inledning och motiveras. Eftersom detta behov inte är någon nyhet finns flertalet lösningar redan på marknaden. En analys av dessa görs i kapitel 2.4. Det sista kapitlet i förstudien beskriver den mjukvara som undersökts inför implementeringsarbetet då verktyget skulle skapas. I kapitlet om Utveckling lämnas en redogörelse över implementeringsarbetet vilket bestod av två huvudmoment: grafisk design samt programutveckling. Kapitlet inleds med en beskrivning av de utvecklingsmiljöer som användes. Därefter redogörs för tillvägagångssätt och resultat av designarbetet - hur en katalog skapad av verktyget skulle se ut. Till sist beskrivs i kapitel 3.3 hur verktyget programtekniskt är uppbyggt - hur det hanterar import och export samt vilka mjukvarutekniker som tillämpats för att uppnå önskade funktionaliteter. Som avslutande del i rapporten analyseras och diskuteras resultatet av projektet - vad som kunde lösts på ett bättre sätt samt hur pass väl syfte och mål uppfyllts. Till sist ges förslag på hur verktyget kan förbättras och vidareutvecklas i framtiden. Kapitel 2 Förstudie Som inledande moment i examensarbetet genomfördes en förstudie. Syftet med denna var att utreda behoven och förutsättningarna kring ett katalogverktyg samt utforska lämpliga tekniker och de implementationsmöjligheter som dessa medförde. Som utgångspunkt för förstudien har den kravspecifikation som uppkommit i samband med idéarbete och definition av examensarbetet använts. Kapitlet inleds med en kort beskrivning av den ramsättande kravspecifikationen vilken följs av en redogörelse för konventioner kring produktkataloger i dagsläget. Med utgångspunkt ur detta görs en behovsanalys samt en undersökning av befintliga verktyg och tjänster för kataloggenerering. I sista avsnittet beskrivs de mjukvarumässiga tekniker som ansetts lämpa sig bäst för att implementera katalogverktyget och uppfylla kravspecifikationen. 2.1 Kravspeci kation Inför detta examensarbete togs en kravspecifikation fram för att beskriva innehållet samt sätta ramarna för funktionaliteten i ett kataloggenereringsverktyg. Kravspecifikationen är indelad i två avsnitt: Funktionella krav samt användningskrav. De funktionella kraven beskriver vilket data samt de dataformat som verktyget ska ta in och vilket resultat verktyget ska generera. För att beskriva detta kort ska verktyget ta in ett artikelregister i dokumentformatet MS Excel med tillhörande bilder. Resultatet ska vara en produktkatalog i PDF-format över dessa artiklar, vilka disponerats enligt en fördefinierad layoutmall. I användningskraven beskrivs den datormiljö som förutsätts för användande av verktyget, samt hur gränssnittet mellan användare och verktyg ska fungera. Målet med implementeringsarbetet är att uppfylla de framtagna kraven. Den kompletta kravspecifikationen återfinns i bilaga 11 . 2.2 2.2.1 Produktkataloger Produktkatalogen som företeelse Att publicera en produktkatalog är att som handlare, tillverkare eller grossist ge ut en förteckning över hela eller delar av sitt produktsortiment. Syftet är att marknadsföra sig och nå ut till potentiella kunder; att i ett kompakt och lättöverskådligt format visa upp, lämna information 1 Fortsättningsvis kommer omnämnanden av kravspecifikation syfta till det dokument som återfinns i bilaga 1. 5 6 Förstudie om sina produkter utanför företagets lokaler och till syvende och sist skapa merförsäljning. Detta koncept att marknadsföra sitt sortiment har under modern tid utökats i och med intåget av Internet och e-handel. Ett företags produktförteckning kan numera marknadsföras på ett dynamiskt och interaktivt sätt. Begränsningar en tryckt katalog medför, såsom räckvidd, inaktuell information och rörliga produktionskostnader vid framställning, ersätts av att kunder lätt kan anskaffa aktuell och eftersökt information i en centraliserad webbutik. Dock associerar nog de flesta den traditionella produktkatalogen med en tryckt publikation och trots fördelarna Internet erbjuder finns det situationer där en traditionell papperskatalog lämpar sig bättre, eller åtminstone som komplement. Många företag erbjuder till exempel tjänsten att beställa hem en tryckt produktkatalog via sin hemsida, förmodligen av den enkla anledningen att vissa föredrar att sitta hemma i soffan och bläddra istället för framför en datorskärm. Vid en förutsättningslös utvärdering har följande fördelar med en tryckt produktkatalog kontra en webbsida kunnat identifieras: En produktkatalog kan aktivt användas som reklambroschyr för utskick. Företaget tar kontakt med kunden istället för att passivt vänta på att kunden ska söka sig till dess webbsida. Trots att Internet-användandet ökar finns det målgrupper, exempelvis äldre, som inte kan nås lika lätt via en webbsida. En tryckt produktkatalog kan distribueras utanför datorskärmen, exempelvis i anslutning till butikens lokaler eller via postförsändelser. Inom vissa branscher råder en tradition att publicera en tryckt produktkatalog, något som är etablerat bland ett företags kunder. Som exempel kan nämnas Clas Ohlson, Biltema och IKEA. Marknadsföringsvärdet av tryckta produktkataloger är förmodligen därför stort för dessa företag. En tryckt publikation erbjuder större möjlighet till hög kvalitet på bilder, illustrationer och layout, vilket tilltalar ögat och ökar marknadsföringsvärdet. 2.2.2 Innehålls- och layoutkonventioner Inför detta avsnitt har flertalet produktkataloger inom detaljhandeln studerats. Syftet var att få en överblick över innehålls- och layoutkonventioner och använda dessa slutsatser som grund till den grafiska layouten i kataloggenereringsverktyget. Allmänna konventioner Innehållsmässigt har sex beståndsdelar identifierats vilka tycks finnas i de flesta produktkataloger oavsett sortiment och bransch: En visuellt tilltalande pärm med företagets namn och den period för vilken produktkatalogen gäller. Innehållsförteckning 2.2 Produktkataloger 7 Huvudinnehållet är hela eller delar av företagets produktsortiment. Ett sökbart register över innehållet. Kontaktinformation Köp- och leveransvillkor. Företag som kontinuerligt ger ut produktkataloger väljer också ofta att lyfta fram nyheter eller kampanjvaror på något iögonenfallande sätt. För att höja marknadsföringsvärdet kan även lockande och stämningsfulla miljöbilder infogas, exempelvis för att visa applikationsmöjligheter med en produkt. Eftersom syftet med en produktkatalog främst är marknadsföring måste den tilltala läsaren både visuellt och innehållsmässigt. Layout och grafik är här viktiga verktyg för katalogproducenten för att uppnå detta. Pärmen ska locka läsaren att öppna katalogen, innehållsförteckning, register, köp- och kontaktinformation är hjälpmedel för läsaren som bör vara enkla och tydliga. Ett exempel är att färgkoda innehållsförteckningen och motsvarande produktkategorisidor inne i katalogen, särskilt användbart då produktsortimentet är omfattande. Se figur 2.1 för illustrerande exempel. Den stora massan av en katalog består dock av artiklar ur produktsortimentet och dessa bör förtecknas på ett strukturerat sätt så att läsaren hittar fram till för denne intressanta produkter. Figur 2.1. Färgkodning i innehållsförteckning och i sidhuvud, exempel ur Biltemas katalog 2012/13 Strukturen kan beskrivas med hjälp av nivåer. På högsta nivå delas produkter in i produktkategorier motsvarande katalogens kapitel. Vilken indelningen och ordningen ska vara är subjektivt och bestäms av företages marknadsföringsstrategi. Dock bör en riktlinje vara att läsaren intuitivt kan hitta fram till eftersökt produkt. På nästa nivå struktureras produkterna inom respektive kapitel. Lika och liknande produkter inom samma artikelgrupp bör ligga tillsammans. Vilken den interna sortering mellan produktgrupperna inom kapitlet ska vara är återigen en subjektiv bedömning. 8 Förstudie Nästa strukturnivå motsvarar layouten av produkterna på varje enskild katalogsida. Efter att ha studerat befintliga produktkataloger kan konstateras att det förmodligen finns lika många layoutvarianter som kataloger. En eller flera kolumner, tät eller gles layout, bilder tillsammans med produktbeskrivningar eller bilder för sig och text för sig. Valmöjligheterna är oändliga och kan motiveras av ekonomiskt grundade frågeställningar såsom målgrupp, upplaga, omfattning av produktsortiment med mera. Dock bör en katalog genomgående byggas upp av en konsekvent sidlayout som är lätt för läsaren att tillgodogöra sig. På lägsta nivå återfinns beskrivning och illustrering av varje enskild produkt. Vanligt förekommande beståndsdelar är produktbild, artikelnummer, artikelnamn, beskrivning, förpackningsstorlek och pris. Vilka beståndsdelarna ska vara och layoutval såsom font och textstorlek bör återigen vara konsekvent. Informationsmängd och kvalitet på text- och bildmaterial motiveras av marknadsföringsstrategier. Objektivt sett bör dock bilder vara av hög kvalitet, tydliga och tillräckligt stora för att illustrera produkten. Bilden är det viktigaste elementet i en artikels beskrivning. Texten bör inte vara för omfattande utan kort och kärnfull i ett lättläst typsnitt så att läsaren lätt kan ta till sig informationen. Målet är ju att sälja. Exempel Följande avsnitt beskriver strukturen i två kataloger av olika typ för att ge konkreta exempel på strukturbeskrivningarna ovan. Figur 2.2. Uppslag ur Biltemas katalog Höst/Vinter 2012/13 Biltema är ett detaljhandelsföretag med produkter inom bland annat bil, bygg, fritid och verktyg. De har över 100 varuhus i Norden och över 17 000 artiklar i sitt sortiment. Biltemas produktkatalog hör till en av Nordens största ifråga om upplaga. Den ges ut två gånger per år och trycks varje gång i över 14 miljoner exemplar [15]. Dessa delas ut till alla 2.2 Produktkataloger 9 hushåll runtom varuhusen samt finns fritt tillgängliga i butikslokalerna. Att producera, trycka och ge ut katalogen är gissningsvis alltså en stor kostnadspost för företaget, vilket förhoppningsvis motiveras av den högre omsättning som utgivningen ger. Produktionskostnaden för katalogen behöver alltså hållas nere. En åtgärd tycks vara att trycka katalogen på relativt tunt papper samt litet format (19x21 cm). Den täta layouten, strukturerad i två till fyra kolumner per sida, sparar också på utrymmet. Textstorleken är liten och produktinformationen kortfattad. Produktbilderna är relativt små, oftast frilagda och flera liknande artiklar sammanfogas ibland till en bild med nummerhänvisning till tillhörande textinformation. En risk med tät layout är att en katalogsida upplevs som rörig och läsaren ser inte alla produkter. Den svenska produktkatalogen för Höst/Vinter 2012/13 omfattar 532 sidor. Ett uppslag ur katalogen visas i figur 2.2. Figur 2.3. Uppslag ur Nevotex katalog 2012-2013 Nevotex är ett svenskt grossistföretag inom textilbranschen med norra Europa som marknad. I deras sortiment finns till exempel beklädnadsmaterial såsom möbeltyger och verktyg för textilindustrin. Deras kunder är företag relaterade till textilbranschen, till exempel tapetserare, inredare, sömnadsateljéer och textildetaljister [11]. Nevotex ger ut sin produktkatalog vartannat år till befintliga kunder samt på begäran. En subjektiv bedömning är att katalogen tycks mer stilren och av högre kvalitet än Biltemas katalog. Katalogen trycks i A4-format på bestruket papper med betydligt högre ytvikt. Sidlayouten är gles med mycket outnyttjat utrymme och betydligt färre artiklar per sida, dock konsekvent 10 Förstudie genom hela katalogen med omfattande textinformation i ena kolumnen och stora tydliga bilder i den andra kolumnen. Detta kan medföra att katalogen upplevs som mer lättläst. Dock saknas prisuppgifter för produkterna inne i katalogen och ges istället ut i en separat prislista. En orsak kan vara att Nevotex endast har företagskunder vilket medför att priser kan skilja sig mellan kunder och köptillfällen, exempelvis på grund av mängd- och förmånsrabatter samt varierande leverantörspriser. En fördel med att utelämna prisinformation är dock att en aktuell produktkatalog kan ges ut med längre intervall eftersom sortimentet hålls relativt statiskt, vilket kompenserar för den högre material- och produktionskostnad denna typ av katalog medför. Den svenska produktkatalogen för 2012/2013 omfattar 280 sidor. Ett uppslag ur katalogen visas i figur 2.3. 2.3 Behovsanalys Detta kapitel beskriver de behov av integrering och effektivisering som observerats i samband med framställning av en produktkatalog och hur en analys av dessa behov resulterat i idén att skapa ett kataloggenereringsverktyg. Omfattningen av en katalogproduktion kan variera kraftigt beroende på storlek på utgivande företag, storlek på produktsortiment, kvalitetsnivå, budget, marknadsföringssyfte, kompetensnivå med mera. Ofta sätter ekonomiska incitament och resurser gränsen för omfattningen. Variationerna kan illustreras med två tänkta ytterligheter: Företag A är ett enmansföretag som ska ge ut ett produkthäfte om 10 sidor med säsongens kampanjvaror. Häftet produceras av företagsinnehavaren med MS Word som layoutprogram. Produktbilderna som ska användas i katalogen är tagna med en generisk kompakt digitalkamera och efterbehandlas ej. Häftet skrivs ut med hjälp av en bläckstråleskrivare för hemmiljö i ett hundratal exemplar vilka skickas per post till för företaget kända kunder. Företag B är ett internationellt företag som producerar ett tiotal kataloger per år över olika delar av sitt mycket omfattande produktsortiment. Dessa ska ges ut i en upplaga om 10 miljoner exemplar i ett flertal länder vilket medför att katalogerna måste produceras i ett antal språkligt skilda versioner. Inom företaget finns en egen produktionslinje för katalogframställning och denna avdelning omfattar ett femtiotal anställda. Arbetsroller som förekommer är flertalet fotografer, art director, formgivare och illustratörer, bildbehandlare, layoutpersonal, trycktekniker med flera. Avdelningen har tillgång till resurser såsom fotostudio, professionella bildbehandlings- och layoutprogram samt eget tryckeri. Även om scenarierna ovan skiljer sig kraftigt har de, och alla varianter där emellan, gemensamt att manuell katalogproduktion är relativt tidskrävande för respektive företag. Det kan visas av en generell beskrivning av momenten i produktionsprocessen: Insamling och produktion av text- och bildmaterial: För det första behövs en förteckning eller databas över de artiklar som ska finnas med i katalogen med tillhörande information, eventuellt utökade produktbeskrivningar samt icke artikelrelaterad text. För det andra ska bildmaterial samlas in eller skapas såsom illustrationer samt miljö- och produktfotografier. Eventuell bildbehandling: Till exempel retuschering, bildbeskärning och färgjustering. 2.3 Behovsanalys 11 Layoutarbete: Sammansättning av allt text- och bildmaterial till ett strukturerat katalogdokument. Utskrift eller tryckning av katalogen. Tidsåtgången vid katalogproduktion varierar beroende på om katalogen produceras för första gången eller endast ska uppdateras för säsongen. I det första fallet kan processen vara tidsödande om alla produkter ska fotograferas och hela katalogdokumentet författas och utformas från grunden. Påföljande upplagor kräver dock endast modifikation av befintligt dokument och eventuell fotografering av nytillkomna produkter vilket därmed kräver betydligt mindre tidsåtgång. Eftersom tid är pengar inom företagsvärlden skulle en tidsbesparing vara gynnande vid katalogproduktion. Ett sätt att lösa detta är att leja ut uppdraget till en produktionsbyrå, men detta medför förmodligen en större kostnad motsvarande uppdragets omfattning. Manuell katalogproduktion kan även innebära att artikelinformation lagras redundant på grund av flera informationskällor vilket medför risk för felaktigheter i katalogens innehåll. Som illustrerande exempel kan nämnas proceduren vid Kåwe Agentur AB. Artikelregistret är integrerat i det vanligt förekommande ekonomisystem Visma Administration där möjlighet ges att exportera artikeldata som ett kalkylblad i MS Excel-formatet .xls. Registret innehåller bland annat artikelnummer, artikelnamn, artikelgrupp, enhet och pris per enhet. En produktbild kan lagras för varje artikel i Visma Administration, dock går det ej att lätt exportera denna bild till en annan källa. Katalogproduktionen sker internt på företaget. MS Publisher används som layoutprogram på ett system där tillgång ej finns till ekonomisystemet. Information från det exporterade artikelregistret infogas eller uppdateras i katalogdokumentet. Produktbilder hämtas direkt från lokala bildkataloger. I Visma Administration finns ej stöd för förpackningsstorlekar utan företaget har istället valt att i vissa fall medföra detta i artikelnamnet jämte eventuella mått på produkten. Produktbeskrivning och förpackningsstorlek författas vid layoutarbetet ur information från artikelnamnet eller efterforskningar. Det färdiga katalogdokumentet lämnas i PDF-format till ett tryckeri och trycks i en upplaga om 100 exemplar per gång. På grund av den relativt lilla upplagan används digitaltryck som tryckteknik. De mjukvaror som används vid Kåwe Agentur för katalogproduktion (Visma Administration, MS Excel och MS Publisher) anses vara mycket vanligt förekommande både i privat och företagsmiljö, ha låga licenskostnader samt låga inlärningskurvor. Det finns därför anledning att förutsätta att många företag, särskilt små företag utan tillgång till en välutvecklad IT-miljö, använder sig av metoder snarlika den vid Kåwe Agentur. Flera risker till felkällor har efter observationer kunnat konstateras. Exempelvis kan artikelinformation hinna förändras i ekonomisystemet under det tidsödande layoutarbetet samt att det finns en risk för felaktigt val av produktbilder. Dessa risker skulle kunna minskas om all nödvändig information fanns lagrad på ett och samma ställe. På marknaden finns flertalet integrerade affärssystem som erbjuder denna lösning, vilket underlättar då produkter ska publiceras i flera medier såsom tryckta produktkataloger och webbutiker. Vissa av dessa system erbjuder även verktyg för generering av produktkataloger - för webbutik eller för tryck. En snabb överblick av sådana system och verktyg ger dock uppfattningen att de har högre inlärningskurvor samt innebär en större kostnad vid köp av licens. Exempel på befintliga verktyg och tjänster för katalogproduktion beskrivs i nästa kapitel. Sammanfattningsvis har observationer av hög tidsåtgång och risk för att infoga fel vid manuell katalogproduktion lett till idén om ett enkelt verktyg för automatiserad katalogproduktion. 12 2.4 Förstudie Be ntliga verktyg och tjänster Detta avsnitt beskriver ett antal befintliga verktyg och tjänster för katalogproduktion. Särskild fokus kommer läggas på verktyg som underlättar layoutarbetet då denna tidstjuv bedöms som den största olägenheten vid manuell katalogproduktion. För- och nackdelar i relation till behoven i föregående kapitel tas upp. 2.4.1 Layoutprogram Tre vanliga layoutprogram för DTP (DeskTop Publishing) är MS Publisher, Adobe InDesign samt QuarkXPress. MS Publisher anses generellt vara enkelt att använda och utan komplexa funktioner. Användargruppen består av privatpersoner, mindre företag samt andra användare som inte arbetar med sidlayout på någon avancerad nivå [20], därav är kostnaden för en programlicens relativt låg. Publisher är plattformsbundet till MS Windows. Tidigare versioner av programmet saknade funktionalitet att konvertera ett dokument till PDF-format, vilket kan anses som hindrande vid distribution av dokument. Senare versioner erbjuder dock denna möjlighet som ett inbyggt verktyg. Det kraftfulla Adobe InDesign är ett marknadsledande program för desktop publishing och används på professionell nivå av användare inom den grafiska branschen [14]. På grund av programmets komplexitet är inlärningskurvan relativt hög för att kunna utnyttja InDesigns alla funktionaliteter, dock erbjuder det fler möjligheter jämfört med Publisher. Eftersom InDesign hör till Adobes programbibliotek, jämte exempelvis bildredigeringsprogrammet Photoshop och illustrationsprogrammet Illustrator, finns funktionalitet för konvertering av dokument till PDF-format inbyggt. Som exempel på funktionalitet som Publisher saknar kan nämnas utökat stöd för textbehandling, möjlighet att infoga rörligt innehåll samt stöd för automatisering vid exempelvis databasstyrt innehåll. En konkurrent till InDesign är QuarkXPress vilket är det layoutprogram som funnits längst. Quark har tidigare ansetts som ledande program för DTP, men på senare tid har InDesign tagit marknadsandelar och anses nu ha störst utbredning. InDesign och Quark finns för plattformarna Mac och Windows. 2.4.2 Katalogproduktion Funktioner inbyggda i layoutprogram I alla tre program ovan finns inbyggd funktionalitet för automatiserad layout och koppling till datakällor. Dessa funktioner kan utnyttjas för katalogproduktion. Då det gäller katalogproduktion på professionell nivå används förmodligen InDesign eller Quark. Publisher i egenskap av enklare program har dock inte lika utvecklad funktionalitet som InDesign eller Quark. I Publisher finns funktionen Koppla dokument/Katalog . Syftet är att skapa en layoutmall vilken kopplas samman med en databas. I mallen för en post i databasen definierar användaren vilka fält i databasen som ska infogas vart. Denna mall fylls vid sammankopplingen i med data från databasen och upprepas så många gånger den får plats på en sida. Sidantalet i det färdiga dokumentet blir dynamiskt mot storleken på databasen. Det finns stöd för att infoga både bilder 2.4 Be ntliga verktyg och tjänster 13 och text. Dock får datakällan endast innehålla text, vilket medför att bilder infogas med hjälp av de sökvägar som anges i databasen. De datakällor som kan användas är exempelvis MS Excel eller annan typ av databas via ODBC (Open DataBase Connectivity) brygga. Termen ODBC förklaras vidare i kapitel 2.5.4. I InDesign finns en liknande funktionalitet benämnd DataMerge [30]. Även här skapas en layoutmall vilken kopplas samman med en databas. Jämfört med Publisher finns dock fler möjligheter vid layoutarbetet såsom att sätta specifika avstånd mellan kolumner och rader, alternativ för hur bilder ska fylla ut sina layoutbehållare samt att begränsa antalet infogade poster per dokument. Funktionen DataMerge kan använda tab- eller kolonseparerade textfiler som datakälla. I MS Excel finns stöd för att exportera kalkylblad till dessa format. Jämfört med behoven som tagits upp i föregående kapitel finns flera för- och nackdelar med de programspecifika funktionerna ovan. Om information i datakällan läggs till, tas bort eller ändras, finns möjlighet att enkelt uppdatera tidigare automatgenererade dokument. Mycket tid sparas vid layoutarbetet eftersom en mall bara behöver skapas. Dock innebär detta en begränsning om layouten i en katalog önskas varieras - alla poster kommer ha samma storlek och interna layout. I och med att storleken på varje behållare är konstant innebär det även problem om exempelvis all text i ett fält inte ryms inom avgränsat område. Publisher har även svårt att hantera stora dokument med många objekt på varje sida. För övrigt innehåll finns möjligheten att infoga sidor manuellt, exempelvis pärm och köpinformation. Dock finns inget stöd i funktionerna ovan för att infoga annat automatiskt innehåll såsom innehållsförteckning eller register. I InDesign finns dock andra verktyg för att exempelvis åstadkomma unika avsnittsnamn i sidhuvudet på varje sida. Plug-in moduler På marknaden finns ett antal fristående plug-in moduler för automatiserad dokumentproduktion till både InDesign [26] och Quark. Generellt sett erbjuder dessa moduler utökad funktionalitet och flexibilitet jämfört med de inbyggda funktionerna ovan exempelvis vid katalogproduktion. En vanligt förekommande modul är 65Bit Softwares EasyCatalog [3] till InDesign. Modulen blir helt integrerad i programmet vilket kräver viss kunskap i hantering av InDesign då katalogen ska skapas. EasyCatalog erbjuder mycket större flexibilitet vid layoutdesign än funktionerna som beskrivs i föregående avsnitt men det kräver istället mer tid för manuellt layoutarbete. Den största styrkan med modulen är att risken för att infoga fel minskas betydligt. Flera typer av datakällor kan användas - allt från tab-separerade textfiler till XML-filer och databaser via ODBC-brygga. Data i datakällan visas som en uppdateringsbar tabell i en separat panel i programmet och kan där sorteras, grupperas och filtreras enligt användarens tycke. Vid layoutarbetet kan flera mallar skapas för hur en produkts enskilda beståndsdelar ska disponeras, eller hur layouten på en hel katalogsida ska disponeras. Dessa mallar lagras i ett mallbibliotek. Layoutarbetet baseras sedan på dra-och-släpp -metoden. Önskad mall infogas i dokumentet och därefter dras önskad post från databasen till denna behållare. Figur 2.4 visar hur denna arbetsmiljö ser ut. På så vis kan hela dokumentet byggas upp produkt för produkt och layoutdesignen kan varieras efter tycke och smak. Det finns även möjlighet att automatiskt generera ett sökbart register till katalogen. Valbara påbyggnadsfunktioner i EasyCatalog kan bland annat öka automatiseringen så att införseln av poster fungerar på liknande sätt som Koppla dokument/Katalog och DataMerge 14 Förstudie ovan, samt uppdatera en ODBC-databas enligt de dataändringar som gjorts. I dagsläget (oktober, 2012) kostar en licens för EasyCatalog i grundkonfiguration över 10.000 kronor och kräver även en licens för InDesign. Detta faktum tillsammans med det att InDesign är ett mer avancerat layoutprogram, ger bedömningen att detta metodval för katalogproduktion bör används på en mer professionell nivå. Figur 2.4. EasyCatalog i InDesign Integrerade funktioner i innehållshanteringssystem Innehållshanteringssystem, eller CMS (Content Management System) [17], är en typ av system som kommit upp i samband med att marknadsföring via Internet ökat och därmed behovet av centralisering och integrering mellan ett företags alla funktioner. Ett CMS är webbaserat och kan koppla samman ett företags webbpubliceringssystem med affärssystem och dokumenthantering. I grunden finns en eller flera databaser och systemets funktioner kan kommas åt via användarvänliga plats- och plattformsoberoende webbgränssnitt baserade på exempelvis PHP, Java eller ASP.NET. Den största funktionaliteten med ett CMS är att skapa och editera innehåll för webbpublicering och i många system finns färdiga grafiska och funktionsbaserade mallar för detta ändamål. Ett CMS är ofta anpassningsbart och användaren väljer de moduler som behövs, exempelvis för blogg, forum, e-handel eller statistik. Många CMS erbjuder även en mängd påbyggnadsmoduler för annat än webbinnehåll, såsom trycksaksproduktion. Ett mycket stort antal både fria och kommersiella system finns på marknaden [19]. Till fria och mest använda CMS hör exempelvis Joomla, Drupal och Wordpress. Eftersom dessa system har öppen källkod är det fritt fram för utvecklare att skapa anpassade lösningar och påbyggnadsmoduler. Bland de kommersiella systemen kan Litium Studio och Magento nämnas. Som illustrerande exempel beskrivs Magentos modul för att skapa kataloger i PDF-format [12]. Katalogens utformning editeras via ett webbinterface och fylls med innehåll från den 2.4 Be ntliga verktyg och tjänster 15 produktdatabas som används vid webbpublicering. Användaren kan fritt editera en första och sista sida via ett WYSIWYG (What You See Is What You Get) gränssnitt, samt välja vilka fördefinierade produktkategorier som ska tas med i katalogen. Generella inställningar kan göras för exempelvis typsnittsstorlek, sidhuvud och sidfot, dock har användaren ingen kontroll över grafisk layout, bildstorlekar, vilka enskilda produkter som ska tas med eller vilka beståndsdelar som ska visas för varje produkt. Modulen har inte heller stöd för en automatiskt genererad innehållsförteckning eller ett register. Figur 2.5 visar arbetsmiljön för kataloggenerering i Magento. Figur 2.5. Kataloggenerering i CMS-systemet Magento Motsvarande moduler i andra CMS kan erbjuda fler eller färre möjligheter. I VirtueMart Catalog för Joomla [29] finns exempelvis möjlighet att inkludera priser eller ej samt klickbara länkar i den genererade PDF-katalogen. GiBi sPrint är en alternativ modul för Joomla [4]. Till skillnad från VirtueMart Catalog tillåts användaren här ange antalet produkter per katalogsida. Ett tredje alternativ är PDF Catalog Creator som är en modul för webbutikssystemet osCommerce [13]. Denna modul kräver en installation lokalt i och med att det är en fristående applikation. Dock ges användaren många fler valmöjligheter. Exempelvis finns möjligheten att välja på 22 stilmallar för den grafiska layouten av katalogen. 16 Förstudie Trots den alltmer utbredda användningen av CMS, finns det många företag som inte använder sig av sådana system. Orsaken kan exempelvis vara att företaget är litet och saknar den kompetens som krävs för anskaffande och nyttjande. Kort sagt: Finns inte ett CMS utesluts de integrerade funktioner som dessa erbjuder som alternativ vid kataloggenerering. 2.4.3 Slutsats På mjukvarumarknaden finns många alternativ för att generera produktkataloger. Program för DTP, med eller utan plug-in moduler, ger fler variationsmöjligheter och större kontroll över den grafiska layouten. Dock krävs mer tid för arbetet samt en viss datorteknisk kunskapsnivå. Funktioner i CMS sparar mycket tid tack vare automatiskt genererade kataloger. Nackdelen är istället begränsningar i möjligheter för grafiska layout samt att användaren är låst till det eventuella CMS som företaget nyttjar. 2.5 Mjukvara En studie i lämpliga tekniker för att implementera och realisera kataloggenereringsverktyget genomfördes. Primärt användes två av kraven i kravspecifikationen som utgångspunkter, nämligen att verktyget i ena änden skulle kunna importera artikelregister i Excel-format och i andra änden producera en katalog i PDF-format. Målet med teknikstudien var därför att hitta program- och dokumentformat som kunder överbrygga gapet däremellan, och inte minst uppfylla resterande krav. Den fullständiga kravspecifikationen återfinns i bilaga 1. 2.5.1 Kort om Excel MS Excel är ett kalkylprogram som ingår i programsviten Microsoft Office och är förmodligen ett program som de flesta datoranvändare känner till och har erfarenhet utav. I detta projekt utnyttjas inte Excel i egenskap av ett kraftfullt kalkyl- och diagramverktyg utan snarare som ett lätthanterligt databasverktyg för att lagra artikeldata. Excel utnyttjas även på grund av dess integrerbarhet mot andra format och system vilket förmodligen kommer sig av dess stora marknadsandel. Som nämnts ovan finns inbyggd funktionalitet i Visma Administration att exportera artikelregister till Excel-formatet .xls och det finns anledning att förutsätta att många andra ekonomisystem också erbjuder den möjligheten. Åt andra hållet finns många exportformat i MS Excel. Bara det faktum att ett kalkylblad kan exporteras som tab-separerad textfil gör att begränsningar för integrering i andra system är obefintliga. Som renodlat databashanteringssystem finns det dock förmodligen kraftfullare och mer väletablerade system såsom MySQL, Oracle Database eller MS Access. Det går exempelvis inte att flera användare hanterar en Excel-databas samtidigt eftersom den lagras som en enskild fil. En annan nackdel är att en Excel-databas inte på ett lätt sätt kan lagras som en relationsdatabas på grund av att det inte finns stöd för unika nyckelfält. En relationsdatabas kan innehålla ett antal tabeller och posterna i dessa relaterar till varandra via identifierande nyckelfält. På så vis minskas mängden upprepande information och databasen blir mindre till storleken och mer lättraverserad. I detta projekt finns dock inte behov av multipel åtkomst. Dessutom anses mängden upprepande information i ett artikelregister vara relativt liten varför fördelarna Excel erbjuder i form av lätthanterlighet och integrerbarhet anses överväga. 2.5 Mjukvara 2.5.2 17 PDF PDF (Portable Document Format) är ett dokumentformat med syfte att på ett uniformt sätt presentera och distribuera digitala dokument, oberoende av den plattform presentationen sker på. Att PDF är ett väl etablerat och standardiserat dokumentformat är största anledningen till att det valts för detta projekt, men även att det lämpar sig som format för högupplösta trycksaker likväl som för webbpublicering eller något däremellan. Bakgrund PDF har sedan 1993 utvecklats av Adobe Systems som under resans gång släppt inte mindre än nio versioner av formatet vilka alla utökat funktionaliteten och möjligheterna. Om det från början var ämnat att presentera text tillsammans med vektor- och bitmapsgrafik, finns nu funktionalitet för exempelvis länkar, kryptering, formulär, 3D-grafik, video och ljud. PDF är ett öppet format som är väl etablerat och sedan juli 2008 är det publicerat i sin helhet som en ISO standard. Tidigare har delmängder av formatet standardiserats, vilka varit avsedda för särskilda användningsområden och branscher. PDF/X används för specifika krav inom exempelvis tryckeribranschen, PDF/A definierar krav för dokument som ska långtidsförvaras, med flera [22]. Program För att användare ska kunna tillgodogöra sig PDF-dokument har Adobe Systems sedan version 2 fritt distribuerat Adobe Reader som bland annat finns som fristående program till de flesta operativsystem, applikation till smartphones samt som plug-in till de flesta webbläsare. De senare har förmodligen bidragit till att PDF idag anses vara gällande format för att distribuera dokument via webben. Om PDF-formatet i sig är ett öppet format så krävs kommersiell mjukvara för att framställa PDF-dokument. Adobe Acrobat är ett program som distribueras av Adobe System och är ämnat för detta ändamål. Tack vare att PDF är ett öppet och numera standardiserat format finns dock PDF-generering idag integrerad i många andra applikationer och system, exempelvis Adobe Creative Suite, MS Office senare programsviter och Open Office för att nämna några. För utvecklare är PDF-formatet fritt tillgängligt för att skapa egna implementationer vilka kan generera, manipulera, visa och distribuera PDF-dokument hörnstenen i detta projekt. Teknik PDF är ett dokumentformat utvecklat ur programspråket PostScript. PostScript används främst för att beskriva utseendet på sidor i digitala dokument där gränssnittet är en skrivare. PostScriptkod, strömmad eller lagrad i .ps-format, exekveras av hård- eller mjukvara med en inbyggd Raster Image Processor (RIP). Som resultat skrivs dokumentet ut på en skrivare eller visas på en datorskärm [23]. Även om syntaxen i PostScript och PDF liknar varandra kan PDF istället ses som en byte-uppbyggd komprimerad delmängd av PostScript där exempelvis flödeskontroll och vissa funktionsanrop skalats bort. Det kan liknas vid att PostScript-koden redan processats av en RIP till entydiga grafiska objekt med tillhörande layout. Detta bidrar till att de grafiska objekten i ett PDF-dokument är korrekta avbildningar av sina original samt att skärmrepresentationen av dokumentet stämmer helt överens med det utskrivna resultatet. Dock är PDF ett mer avancerat och smartare dokumentformat än PostScript i avseendet att det utöver 18 Förstudie grafisk beskrivning innehåller ytterligare funktioner och dokumentinformation. Som exempel kan nämnas följande: Utökat system för bifogade fonter samt fontersättning. Detta säkerställer att typsnittsdesignen på dokumentet bevaras, även då filen visas på ett system där aktuell font saknas. Metadata, såsom titel, författare, nyckelord för indexering, ändringsdatum med mera. Interaktiva objekt såsom interna eller externa hyperlänkar, knappar och ifyllbara formulär. Innehållsförteckning i form av bokmärken. Kryptering och behörighetsbegränsningar, vilket är särskilt användbart vid distribution. Direktiv vid utskrift, exempelvis skalning, utskriftsområde och information om färgseparering vid flerfärgstryck. Strukturen i en PDF-fil medför ytterligare en fördel jämfört med PostScript, nämligen att innehållet kan kommas åt i slumpmässig ordning tack vare korsreferering mellan de objekt som bygger upp filen. Detta skapar ett oberoende mellan sidor och grafiska objekt samt låg informationsredundans. I praktiken innebär det att en användare direkt kan hoppa till sista sidan i ett långt PDF-dokument och få en korrekt presentation på skärmen, medan ett motsvarande PostScript-dokument helt måste processas innan sista sidan kan visas på ett korrekt sätt. Som beskrivs på sidan 38 i standarden för PDF [5] består en PDF-fil i grunden av fyra sektioner vilket illustreras i figur 2.6: Header - anger bland annat PDF-version. Body - uppbyggt av objekt som beskriver innehållet i dokumentet. Korsreferenstabell - nödvändig för att kunna komma åt alla objekt i slumpmässig ordning. Trailer - innehåller till exempel antalet objekt i filen, samt anger var i filen korsreferenstabellen kan hittas. På sidan 13 i standarden för PDF [5] beskrivs de åtta typer av objekt som kan finnas i en PDF-fil. Som exempel kan nämnas nummer, namn och dataströmmar. Vanligast är dock objektet Dictionary (ordlista) vilken är en gruppering av flera namngivna objekt (eller referenser till andra objekt). En Dictionary kan sägas beskriva ett innehållsobjekt i dokumentet. Som exempel kan en hel sida i ett dokument beskrivas av en Dictionary, vilken då anger vilka fonter som används på sidan, vilka bilder som ska finnas med och vart de ska placeras, textinnehållet med mera. Dessa kan i sin tur vara egna Dictionaries vilka beskriver egenskaper för respektive objekt. Objekt 0 4 i figur 2.6 är ett Dictionary-objekt. Ett objekt kan vara direkt eller indirekt. Indirekta objekt, i kombination med korsreferenstabellen, medför att ett objekt kan vara lokaliserat var som helst i filen och att en PDF-fil därför inte behöver processas sekventiellt. Om ett objekt är indirekt, vilket är vanligast förekommande, tilldelas detta per automatik ett indexnummer. Dessa nummer används av korsreferenstabellen samt för referering mellan föräldra- och barnobjekt. 2.5 Mjukvara 19 Figur 2.6. Sektionerna i en PDF-fil 20 Förstudie 2.5.3 Javabiblioteket iText Tidigt i projektet beslutades att utveckla kataloggenereringsverktyget i programmeringsspråket Java. Eftersom dokumentformatet PDF är så pass utbrett och standardiserat som det är, undersöktes om det fanns färdiga programbibliotek för Java vilka kunde generera PDF-dokument. Webb-sökningar resulterade i referenser till tredjeparts programbibliotek såsom Apache PDFBox,BFO:s Java-bibliotek samt iText. Flera faktor gjorde att iText snabbt bedömdes som ett lämpligt val: iText är ett öppet programbibliotek gällande under GNU Affero General Public License2 [7], därmed fritt att använda inom detta projekt. Programbiblioteket har ett omfattande API (Application Programming Interface) för att skapa, läsa och uppdatera PDF-dokument. Därav gjordes bedömningen att det borde tillgodose behoven för detta projekt. Enligt uppgift på sidan 5 i boken iText in Action [28] är iText världsledande som F/OSS (Free and Open Source Software) bibliotek. Detta stöds även av att många oberoende källor refererar till iText som ett lämpligt val för PDF-hantering. iText är väl dokumenterat både med litteratur [28] samt med HTML-dokumentation skapad i Java [6]. iText har varit under utveckling sedan 1998 och uppdateras ständigt med ny och utökad funktionalitet. Det är därför rimligt att anta att det kommer finnas stöd för programbiblioteket länge än. iText täcker in funktionaliteter för att programmatiskt skapa, läsa och manipulera PDFdokument på ett automatiserat sätt. Syftet med applikationer som använder sig av iText är alltså att inget mellanliggande mjukvaruprogram för att manuellt skapa innehåll ska krävas för att åstadkomma ett dokument i PDF-format. Detta lämpar sig särskilt för dynamiskt innehåll som skapas i realtid från exempelvis en databas, eller då innehållet är mycket omfattande. Generellt sett finns det mesta av funktionaliteten i PDF-standarden inbyggt i API:t för iText. Det finns exempelvis stöd för kryptering, generering och automatiskt ifyllande av formulär, direktkonvertering av XML till PDF, vattenstämplar, sammanfoga flera existerande PDF-dokument till ett samt extrahera text, bara för att nämna en del. Grundläggande arkitektur för att skapa ett PDF-dokument med iText består av fem steg: Först skapas ett dokument-objekt till vilket innehållet ska adderas. Därefter anropas en instans av en så kallad PDFWriter som kan betraktas som en tolk vilken översätter adderade Java-objekt till korrekt PDF-syntax. De sista tre stegen består i att öppna dokumentet, addera innehåll och därefter stänga dokumentet. Figur 2.7 visar ett enkelt kod-exempel och dess resultat. 2 Upphovsrättslicens för fri programvara. Om en applikation använder programvara gällande under GNU GPL, måste dess källkod göras allmänt tillgänglig vid distribution av applikationen. 2.5 Mjukvara 21 Figur 2.7. iText exempel 2.5.4 Excel-import i Java Enligt det första kravet i kravspecifikationen ska kataloggenereringsverktyget kunna importera ett artikelregister lagrat i något av formaten möjliga i MS Excel. Som nämnts tidigare är motivet till detta att Excel har en utbredd användargrupp, vilket gör det troligt att många användare har möjlighet att lagra artikelregister med hjälp av detta program. Dessutom motiveras detta ytterligare av att det vanligt förekommande ekonomisystemet Visma Administration ger möjlighet att exportera artikelregister till Excel-format. Flera lagringsformat stöds av MS Excel, bland annat XML, tabbavgränsad textfil och semikolonavgränsad textfil. Integrerbarheten mot andra applikationer bedöms därför som stor. Grundformatet i Excel är dock det programspecifika .xls3 . En användbarhetsaspekt vid hantering av kataloggenereringsverktyget är att ju färre steg och åtgärder användaren behöver 3 För dokument skapade i MS Excel 2007 och senare gäller motsvarande .xlsx-formatet, men då kravspecifikationen endast kräver kompabilitet med ett Excel-format, kommer stöd för .xslx-filer ej implementeras 22 Förstudie vidta för att skapa sin katalog, desto mer lätthanterligt upplevs verktyget samt att risken för fel minskar. Då det bedöms som troligast att ett artikelregister skapat i Excel är lagrat som .xls-fil behöver därför verktyget kunna importera artikelregister i detta format. Efterforskningar resulterade i två alternativa programbibliotek för Java vilka ansågs uppfylla behoven för detta projekt: Apache POI samt JExcel. Även ett tredje mer generellt sätt för databasåtkomst undersöktes. Apache POI är ett fritt Java API skapat av Apache Software Foundation [1]. Syftet med API:t är att kunna skapa, läsa och manipulera dokument i något av formaten baserade på OOXML (Office Open XML) standarden samt OLE2 (Microsoft-formatet Object Linking and Embedding Compound Document). Detta inkluderar bland annat dokument skapade i MS Word, MS Publisher samt MS Excel. Apache POI består av flera programbibliotek - ett för varje dokumentformat. Biblioteket HSSF stöder .xls-formatet och biblioteket XSSF stöder .xlsx-formatet. Därav är Apache POI kompatibelt även med MS Excel 2007 och senare. JExcel är ett Java API fritt att använda under GNU LGPL licens4 [8]. JExcel byggs upp av ett programbibliotek med funktionalitet för att skapa, läsa och manipulera filer i .xls-format. Funktionalitet som stöder .xlsx-formatet finns ej i dagsläget. Nackdelen med dessa externa Java-bibliotek är dock att de båda kräver mycket minnesutrymme vid körning av mycket stora kalkylblad. Anledningen är att data från aktuellt kalkylblad helt läses in i minnet, vilket kan ta tid, för att sedan därifrån behandlas av aktuell applikation. Apache POI erbjuder ett så kallat Event API för att kringgå detta, men denna lösning fungerar endast för .xls-dokument, ej .xlsx. För att det inte ska finnas någon begränsning med kataloggenereringsverktyget för hur omfattande ett artikelregister kan vara, har ett mer generellt sätt för databasåtkomst utretts. Inom Java:s standard-API finns stöd för Open Database Connectivity (ODBC), vilket är en standardiserad metod för åtkomst av databaser [21]. I en Java-applikation definieras en ODBCbrygga vilken gör att data från en viss typ av datakälla kan hämtas med hjälp av SQL-frågor (Structured Query Language). Både i Windows- och MacOS-miljöer finns inbyggt stöd för en ODBC-brygga där datakällan är ett Excel-dokument. Om denna metod implementeras i kataloggenereringsverktyget motverkas minnesproblemet, samt att det öppnar upp för att lätt byta till andra typer av datakällor än Excel. 2.5.5 XML Extensible Markup Language (XML) är ett så kallat märkspråk vars syfte är att skapa en standard för utväxling av data mellan olika informationssystem, då främst över Internet [25]. XML-strukturen består av två komponenter: En textfil innehållande uppmärkt data i en noduppbyggd trädstruktur, samt en tillhörande dokumentmall vilken beskriver regler för den struktur efter vilken XML-dokumentet är uppbyggt. Båda delarna kan definieras av användaren vilket ger stora friheter och möjligheter med hur XML kan användas. En annan egenskap med XML är dess enkelhet då människa som maskin kan läsa och tillgodogöra sig innehållet i ett XML-dokument. Dessutom är syntaxen för XML mycket enkel vilket gör att 4 Om en applikation använder programvara gällande under GNU LGPL, tillåts distribution utan att göra källkoden allmänt tillgänglig 2.5 Mjukvara 23 det inte är särskilt komplicerat att skapa ett XML-dokument. Ett enkelt exempel visas i figur 2.8. Figur 2.8. XML exempel Andra applikationer tillgodogör sig innehållet i ett XML-dokument genom att bearbeta ett XML-dokument via en så kallad parser, eller tolk. För att denna bearbetning ska fungera optimalt bör det aktuella XML-dokumentet inneha vissa egenskaper. XML-dokumentet bör vara väl utformat. Detta innebär att syntax för XML följs, exempelvis korrekt nästling av element, att endast tecken tillåtna i den teckenkodning som specificerats finns i dokumentet samt att endast ett rotelement förekommer. XML-dokumentet bör även vara giltigt. Detta innebär att en tillhörande dokumentmall, eller schema, finns i vilken det bland annat är specificerat vilka element som få förekomma, vilka attribut som är giltiga för respektive element, i vilken ordning elementen får förekomma, samt vilken föräldra-barn struktur som är giltig. Vanligt förekommande typer av dokumentmallar är DTD (Document Type Definition) samt XML schema. XML schema anses ha en mer intuitivt syntax samt vara mer utbyggt än DTD. Exempelvis finns möjligheten att ange hur många gånger ett viss element får förekomma i XML-dokumentet. I detta projekt ses möjligheter att definiera textuella layoutmallar samt programstrukturellt data med hjälp av XML. Tillämpningar av XML Tack vare den enkelhet, flexibilitet och det plattformsoberoende XML medför finns idag många tekniker som baserats på märkspråket. Bland specifikationer som är nära besläktade med XML kan nämnas XML Namespace, XPath och XSLT. XML Namespace, eller namnrymd, används för att undvika tvetydigheter vid namngivning av element. Två olika typer av element tillåts då 24 Förstudie inte att namnges på samma sätt. XPath är ett frågespråk framtaget för att enkelt kunna adressera sökta noder i ett XML-dokument. XSLT är ett märkspråk som används för att transformera ett XML-dokument till något annat, exempelvis ett nytt XML-dokument bestående av utvalda delar av det gamla, ett HTML-dokument eller ren text. XSLT utnyttjar XPath-uttryck i det XSLT-schema som specificerar hur transformationen ska gå till. Många nya programmeringsspråk som baseras på XML har utvecklats, exempelvis XHTML för webbutveckling samt RSS för webbaserade nyhetsflöden. Dessutom baseras många nyare dokumentformat för exempelvis ordbehandling, kalkylblad och presentation på XML. Till dessa hör MS Excel:s format .xlsx. I de flesta större programmeringsspråk finns API:n för att möjliggöra implementering av XML då applikationer och program skapas. Gränssnitt mellan Java och XML I Java finns ett väl utbyggt stöd för XML-tillämpningar både i form av standardpaket och fristående API:n för att tolka, bearbeta och skapa XML-dokument. Två huvudkategorier av XML parsers kommer att tas upp: trädstrukturerade samt strömmande. Det trädstrukturerade DOM (Document Object Model) är i grunden en plattforms- och språkoberoende konvention som bygger på att innehåll i ett dokument representeras som objekt i en trädstruktur [2] [16]. DOM-baserade XML-parsers tillåter godtycklig åtkomst av objekten vilket görs möjligt av att hela eller delar av dokumentet vid varje givet ögonblick finns lagrat i datorminnet. Detta medför att DOM-baserade applikationer är relativt minneskrävande, men ger istället flexibilitet då ett objekt kan kommas åt när som helst. DOM-baserade parsers lämpar sig bäst för mindre XML-dokument med en på förhand känd struktur eller då XML-dokument ska manipuleras eller skapas. Strömmande parsers, även benämnt SAX (Simple API for XML) traverserar ett XMLdokument seriellt från början till slut. På så vis krävs minimalt med datorminne på bekostnad av att endast en ögonblicksbild av XML-dokumentet ges vid ett givet tillfälle. Strömmande parsers lämpar sig bäst då det finns krav på låg minnesanvändning samt då innehållet i ett XML-dokument ska trigga särskilda händelser i en applikation [24]. Exempel på vanliga Java API:n för XML-hantering är JAXP (Java API for XML Processing) samt JDOM. JAXP är ett API utvecklat av Sun Microsystems och innehåller stöd för olika typer av parsers. DOM för godtycklig åtkomst av XML-data samt bygga XML-dokument, SAX för seriell åtkomst och händelsestyrning samt StAX (Streaming API for XML) vilket kan ses som ett mellanting av DOM och SAX. Dessutom finn ett XSLT gränssnitt för transformation av XML-dokument [18]. JDOM är ett öppet programbibliotek med stöd för DOM, SAX, XPath och XSLT. JDOM är inte lika komplext som JAXP och därmed mer effektivt att implementera XML med. Enligt utvecklarnas utsago är JDOM intuitivt och lättare att börja använda då dess arkitektur är uppbyggd särskilt för Java-plattformen och påminner mycket om standardimplementeringar i Java [9]. Kapitel 3 Utveckling Målet med utvecklingsarbetet var att ta fram en grafisk kataloglayout lämplig för automatisk katalogframställning samt implementera ett verktyg som skapar en produktkatalog för ett givet artikelregister där den fördefinierade layouten utnyttjas. Målet skulle vara nått då kraven i kravspecifikationen uppfyllts, se bilaga 1. Under förstudiearbetet gjordes efterforskningar i konventioner kring kataloglayouter, befintliga verktyg för katalogframställning samt lämpliga tekniker. Resultaten av förstudien tillämpades under utvecklingsarbetet vilket beskrivs i detta kapitel. Som inledning redogörs för de utvecklingsmiljöer som utnyttjades under arbetets gång. Därpå beskrivs arbetet med framtagning av grafisk kataloglayout följt av hur verktyget programtekniskt implementerades. 3.1 Utvecklingsmiljö Grafik utvecklades till största delen i Adobe Illustrator, främst på grund av stöd för vektorgrafik samt möjligheten att konvertera bilder till PDF-dokument. Motivet till detta förklaras närmare i kapitel 3.3.2 fjärde avsnittet nedan. Ett tidigt val gjordes att programvaran skulle utvecklas i programmeringsspråket Java. För detta krävdes tillgång till Java Development Kit (JDK) vilket innefattar utvecklingsverktyg samt ett omfattande programbibliotek kallat Java API. För att underlätta utvecklingen användes den fria programmeringsmiljön Eclipse. Eclipse är en populär utvecklingsmiljö som används av många Java-utvecklare och ansågs därför som ett pålitligt och lämpligt utvecklingsverktyg. I Eclipse finns stöd för kompilering och syntaxkontroll on-the-fly vilket avsevärt minskar tid för felsökning. För ytterligare utvecklingsstöd användes det öppna versionshanteringssystemet Subversion (SVN). Versionshantering grundar sig i att exempelvis dokument, filer och källkod sparas i versioner vilket gör det möjligt att backa tillbaka till och återskapa en tidigare version om detta skulle önskas. Det ger även möjlighet till parallell utveckling av flera versioner vilket kan vara användbart om en gammal utgåva av ett projekt behöver rättas. Versionshantering anses särskilt användbart vid programvaruutveckling eller då flera användare skapar och manipulerar filer inom ett och samma projekt samtidigt. Inom detta projekt utnyttjades SVN särskilt för att lätt kunna backa tillbaka till tidigare versioner av källkoden samt för att sätta milstolpar i form av utgåvor av verktyget. SVN utnyttjades även som ett sätt att säkerhetskopiera allt digitalt innehåll i projektet. 25 26 3.2 Utveckling Gra sk design Design av den grafiska kataloglayouten skedde inkrementellt: Ett första utkast togs fram vars resultat grundade sig i förstudiearbetet och visade det grafiska slutresultat som skulle eftersträvas under implementeringen. Under utvecklingens gång fick dock vissa modifikationer och nedskalningar göras beroende på vad som tidsmässigt och tekniskt var möjligt att realisera inom ramarna för examensarbetet. Bilder och illustrationer nedan över den grafiska designen visar det slutgiltiga resultatet. 3.2.1 Övergripande kataloglayout och design Enligt kravspecifikationens krav K6 skulle den resulterande produktkatalogen innehålla vissa beståndsdelar. Därav togs designförslag fram för en katalog i A4-format bestående av följande komponenter: Pärm med företagets namn samt säsong Kontaktuppgifter Köpinformation Innehållsförteckning Artiklar sorterade på artikelgrupp Register En övergripande riktlinje vid design av dessa delar var att hålla grafiken neutral och enkel för att passa och tilltala en bred målgrupp, både vad gäller användare av katalogverktyget och läsare av resulterande kataloger. Framför allt var syftet att grafiken skulle lämpa sig bra för produktsortiment av vitt skilda typer. Som diskuterades och visades i förstudiekapitel 2.3 - Behovsanalys, sker den mesta katalogproduktion idag mer eller mindre manuellt. På bekostnad av tid tillåter detta att en produktkatalogs utformning anpassas på ett intuitivt sätt mot dess innehåll. Via WYSIWYGgränssnitt kan katalogproducenten måla upp katalogen artikel för artikel och sida för sida. Utmaningen då layouten ska skapas per automatik är att åstadkomma ett lika välformat resultat som om katalogen skapats för hand. Vid designarbetet behövde därför hänsyn även tas till de varierande behov av layout som kataloggenereringsverktyget var tänkt att stödja. 3.2.2 Artikellayout Det viktigaste i en produktkatalog är dess produktförteckning varför största delen av designarbetet lades på artikellayouten. Ett första beslut var att designa mot en gles artikellayout vilket grundade sig i flera motiv. I enlighet med principer för användarcentrerad utveckling genomfördes en informell undersökning där olika typer av produktkataloger visades för ett antal personer. Åsikter från denna undersökning visade på att kataloger med gles artikellayout är mer estetiskt tilltalande samt upplevs som mer lättlästa och mindre röriga då produktbilder och textstorlek kan vara större och ett kataloguppslag innehåller färre antal artiklar. 3.2 Gra sk design 27 En gles artikellayout kräver mindre dynamik då artiklar ska disponeras över en sida i exempelvis en enda kolumn. Därav underlättas mjukvaruutvecklingen då ett färre antal eventualiteter behöver täckas in. Då en gles artikellayout innehåller mycket tomma utrymmen tillåter det en större variation av informationsinnehållet för en enskild artikel. Som exempel kan nämnas textmängd, bildstorlek och bildförhållande samt ett varierande antal bilder per artikel. Ett designförslag för en artikel i en gles enkolumnslayout togs fram. De informationselement som enligt kravspecifikationen skulle ingå för en artikel var följande, med tillägg för variant: A. Artikelgrupp (ingår ej i artikellayouten) B. Artikelnamn C. Artikelinformation D. Artikelnummer E. Enhet, exempelvis styck, meter, kilogram F. Förpackningsmängd G. Pris per enhet H. Bild I. Variant (tillägg) Figur 3.1 nedan visar disponeringen av respektive element. Artikelgrupp ingår inte i artikellayouten utan används endast i sorteringssyfte. Figur 3.1. Layout för artikel Disponeringen av respektive informationselement grundade sig i konventioner som enligt förstudiekapitel 2.2.2 - Innehålls- och layoutkonventioner visat sig råda för katalogproduktion. För textelement valdes typsnittet Quicksand som upplevdes som lättläst och tilltalande oavsett storlek och visningsmedium. Vikt lades även vid att typsnittet skulle inneha en öppen licens eftersom katalogverktyget är avsett att användas för kommersiellt bruk [10]. Avdelare och tomrum utnyttjades för att underlätta läsbarheten. Produktbilder tilläts uppta en tredjedel av en sidas bredd samt en femtedel av dess höjd då bilder ansågs som de viktigaste elementen för läsaren. För den eventualitet att produktbild saknas skapades även en ersättningsbild med syfte att informera om detta. 28 Utveckling Med stöd ur förstudien ansågs dock vissa layout-variationer förekomma varför utkast för dessa också togs fram enligt följande. I de fall flera liknande artiklar skulle visa en och samma bild togs beslut att gruppera dessa, vilket visas i figur 3.2. Här kommer tillägget Variant väl till pass för att som läsare kunna skilja liknande artiklar åt. Detta visas vid pil I i figur 3.2. Detta skulle exempelvis kunna förekomma då endast färg eller storlek skiljer artiklar åt. Det omvända förhållandes skulle också kunna förekomma, det vill säga att en artikel behövde visa flera bilder. Hänsyn togs även till varianter där ett eller flera informationselement utelämnats. De två senare layout-varianterna visas i figur 3.3, men dessa funktionaliteter implementerades dock ej i verktyget. Figur 3.2. Gruppering av liknande artiklar Figur 3.3. En artikel - flera bilder Ett kataloguppslag som illustrerar den fullständiga sido-layouten visas i figur 3.4. 3.2 Gra sk design 29 Figur 3.4. Fullständig sido-layout 3.2.3 Övrig layout Artiklarna skulle enligt kravspecifikationen sorteras på artikelgrupp. Detta öppnade för att dela in katalogen i kapitel, ett per artikelgrupp. Design för innehållsförteckning över dessa kapitel togs fram, se figur 3.5, samt för titelsidor till varje kapitel, se figur 3.6. Här togs även beslutet att koda varje kapitel med en unik färg i innehållsförteckning samt i sidhuvudet på motsvarande sidor för att ge överblick samt underlätta sökbarheten i katalogen1 . Funktionen med titelsidor inför varje kapitel implementerades dock ej i verktyget. Till sist skapades design för artikelregister, sida för kontakt- och köpinformation samt pärm. 3.2.4 Gra skt material En grundläggande idé vid designarbetet var att varje grafiskt element i kataloglayouten lätt skulle kunna bytas ut. Syftet med detta var att underlätta för användare av verktyget att anpassa katalogen mot exempelvis ett företags grafiska profil. Därav lagrades all grafik som bild-filer, en för varje grafiskt element såsom linjer, bakgrunder samt logotyper, vilka lätt kunde bytas ut. Denna möjlighet underlättade även implementeringen av verktyget. 1 Som visades i förstudien verkar färgkodning vara en vedertagen konvention bland många katalogproducenter. 30 Utveckling Figur 3.5. Layout för innehållsförteckning 3.3 Figur 3.6. Layout för titelsida till kapitel Programutveckling Då ett första utkast till grafisk layout av katalogen var fastställt, var det dags att implementera denna och önskad funktionalitet i kod. Riktlinjer under implementeringen var en modulär uppbyggnad av programmet samt att möjliggöra utveckling av utökad funktionalitet i framtiden. 3.3.1 Verktygets funktionaliteter Målet med programutvecklingen inom ramarna för examensarbetet var att implementera kataloggenereringsverktyget med de funktionaliteter som listats i kravspecifikationen. Som beskrivits i förstudien består dessa funktionaliteter grovt i att generera en produktförteckning i dokumentformatet PDF där informationsinnehållet hämtats från ett artikelregister och den grafiska utformningen från en fördefinierad mall. Dessa funktionaliteter illustreras i figur 3.7 över programflödet. Figur 3.7. Programflöde 3.3 Programutveckling 3.3.2 31 Implementering För att implementera funktionaliteterna ovan i Java användes utöver standardpaket de fristående programbibliotek som beskrivits i förstudien. Apache POI användes för att importera artikelregister lagrade i MS Excel-format, JDOM för att importera XML-data såsom grafisk mall lagrad i XML samt informationsdata att infogas i katalogen. För att exportera till formatet PDF användes utvalda delar av Java-biblioteket iText. Import och hantering av artikelregister Stor vikt lades vid att importera data från ett artikelregister på ett strukturerat sätt då detta sågs som en grundsten i projektet. En Java-klass skapades för att hantera import av data ur ett Excel-dokument, men data i sig lagrades artikel för artikel i en datastruktur vilken var oberoende av det format som artikeldatabasen lagrades i. På så vis skapades möjlighet att byta ut importklassen för att kunna hantera andra databasformat i framtiden. För importen från Excelregister gjordes för enkelhets skull antagandet att kolumner för exempelvis artikelnummer, pris samt sökväg för bild var sorterade i en viss förutbestämd ordning. (Figur 3.8 visar ett utdrag ur det artikelregister som användes under examensarbetet.) Detta antagande grundade sig i två saker. Dels att ekonomisystemet Visma exporterade artikelregister till Excel-format med en viss kolumnordning, dels att kolumnordningen hade betydelse för de klasser som användes ur Apache POI. Vid import med hjälp av dessa klasser refereras nämligen till en specifik cell i kalkylbladet varur data ska hämtas. Därför var det viktigt att i ett första skede anpassa importklassen så att exempelvis artikelnummer importerades till rätt fält i datastrukturen. En framtida målsättning är dock att i en extern XML-fil, jämte databastyp, kunna ange egenskaper för databasen såsom datatyper och kolumnordning. På så sätt ökas anpassningsbarheten vid användning av verktyget. Ett av syftena med detta projekt var även att kunna importera och publicera en obegränsad mängd artiklar med hjälp av verktyget. Här lämpade sig Apache POI bra då det finns funktionalitet i programbiblioteket för att ta reda antalet rader som utnyttjas i ett kalkylblad. Detta i kombination med iteration ger möjlighet att hantera en obegränsad mängd artiklar. En möjlig begränsning som togs upp i förstudien men dock inte undersöktes var om resursen av datorminne som verktyget skulle allokera skulle räcka till för en stor mängd artiklar. Möjligheten fanns här att använda en så kallad JDBC-ODBC-brygga för att skapa äkta databasstöd och på så vis motverka eventuella minnesproblem. Dock skulle denna lösning innebära en större ändring i import-klassen varför detta i nuläget ännu inte implementerats. Variationer och fel antogs kunna förekomma i ett artikelregister i Excel-format. Hantering av de som ansågs vikigast implementerades i verktyget. Till dessa hörde särskilt avsaknad av data. För de artikelposter som innehöll en eller flera tomma celler ersattes dessa fält i datastrukturen med förutbestämda värden. Som exempel kan nämnas att saknad sökväg till produktbild ersattes med sökväg till en fördefinierad bild-saknas -bild samt att ett streck infogades då textuellt eller numerärt data saknades. Fält som nyttjades för intern strukturering och sortering av artikelposterna skulle dock av förklarliga skäl inte godtas som tomma. Punkt K6 i kravspecifikationen angav att artiklarna skulle vara sorterade i artikelgruppsordning. Detta för att möjliggöra en kapitelindelning på artikelgruppsnivå i den färdiga katalogen. Ett mål med implementeringen var därför att strukturera importerat artikeldata för att uppfylla detta krav. Beslut togs att sorteringen skulle ske på två nivåer: i första hand på 32 Utveckling Figur 3.8. Utdrag ur artikelregistret artikelgrupp och i andra hand på artikelnamn. Därav kunde alltså dessa fält inte godtas som tomma i artikelregistret. Den sorterade datastrukturen skulle därefter vara färdig att exportera löpande till ett katalogdokument. Dock återstod denna sorteringsfunktionalitet att implementera vid programutvecklingens slut. I nuläget importeras därför ett redan på förhand sorterat artikelregister. Import och hantering av gra sk mall Punkt K5 i kravspecifikationen angav att verktyget vid körning skulle utnyttja en grafisk mall för layoutkomponeringen av katalogen. Syftet med detta krav var att som användare av verktyget lätt kunna ange och ändra egenskaper för layout såsom koordinater för objekt i katalogdokumentet, typsnitt för text, storlek på produktbilder med mera. Beslut togs att skapa denna mall som ett XML-dokument där sådana egenskaper kunde anges som data i väl uppmärkta element. Hophörande element grupperades även i en trädstruktur för att underlätta hantering av och sökbarhet i dokumentet. Strukturprincipen illustreras i figur 3.9. I verktyget skapades därefter en datastruktur till vilken grafiskt data kunde importeras. Även här, liksom för import av artikelregistret ovan, skapades en särskild Java-klass för att hantera import av data i just XML-format. I en framtida utveckling av verktyget ges på så vis möjlighet att byta filformat och tillhörande importklass för grafiskt data utan att datastrukturen behöver implementeras om. För att sedan importera ett särskilt element från XML-dokumentet med hjälp av JDOM behövde detta i import-klassen adresseras specifikt hela vägen från rot-elementet. Därav behövde strukturen i XML-dokumentet vara definierad på förhand. 3.3 Programutveckling 33 Figur 3.9. XML-dokumentets strukturprincip I ett första skede implementerades endast import för de grundläggande grafiska egenskaperna. Till dessa hörde bland annat dimensioner för den yta en artikel skulle allokera på en katalogsida, relativa koordinater för varje text- och bildobjekt inom en artikel samt storlek på produktbild. Många fler egenskaper skulle dock kunna anges externt i mallen för katalogen. Som exempel kan nämnas marginaler i katalogdokumentet samt i vilken ordning katalogens delar ska förekomma. Vissa användare skulle exempelvis kunna föredra att köpinformationen presenteras sist istället för först. Import och hantering av informationsdata Förutom artikeldata fanns även krav på import av informationsdata såsom köpinformation, sökväg till företagets logotyp och kontaktuppgifter. Även här togs beslutet att lagra dessa data i ett XML-dokument på samma sätt som för den grafiska mallen. Undantaget var köpinformation som baserat på förstudien bedömdes kunna vara omfattande i textmängd. Därför lagrades 34 Utveckling endast sökvägen till en extern fil innehållande denna köpinformation i XML-dokumentet. Trots att import av informationsdata skulle ske på samma sätt som för den grafiska mallen, skapades en separat klass för detta. Motivet var återigen modularitet - att vid framtida utveckling kunna byta format och metod för enskilda delar av verktyget. Allt XML-lagrat informationsdata importerades med hjälp av en JDOM-baserad import-klass. Även här skapades en separat datastruktur för att lagra detta data i datorminnet. Undantaget var köpinformationen vilken importerades seriellt via en filström till en separat minnesbuffert varifrån det sedan hämtades av export-klassen nedan. Export av katalog Det mesta av arbetet med implementeringen lades på exportfunktionen i verktyget. Många både hög- och lågnivåfunktioner i Java-biblioteket iText användes för att skapa en produktkatalog som ett PDF-dokument. Bland högnivåfunktioner utnyttjades bland annat enkla kommandon för att infoga nya sidor sist i dokumentet eller hela textstycken där positionering, rad- och sidbrytningar skedde per automatik. Lågnivåfunktioner gav istället möjligheten att placera objekt såsom bilder och textstycken vid absoluta koordinater2 , ange typsnitt, storlek och justering för angivet textstycke eller arbeta i olika lager på en dokumentsida. Just lågnivåfunktioner kom väl till pass för att implementera de layoutinställningar som angavs i den externa grafiska mallen. En iText-baserad export-klass skapades i vilken en katalog genererades i två iterationer. Figur 3.10 illustrerar flödesschemat. Under första iterationen skapades PDF-dokumentet och katalogens respektive delar adderades i kronologisk ordning3 . Under andra iterationen öppnades det redan genererade PDF-dokumentet på nytt och innehållsförteckning, sidhuvuden och sidfötter adderades innehållande sidreferenser som kalkylerats under första iterationen. Som inledande momentet i första iterationen angavs katalogens genomgående egenskaper såsom sidformat, marginaler och typsnitt (a). Därefter kunde innehåll börja infogas. Katalogens fram- och baksida samt sida för kontakt- och köpinformation ansågs rymma mestadels icke dynamiskt innehåll varför objekt placerades vid absoluta koordinater. På framsidan (b) placerades textfält för titel och säsong samt bildobjekt för företagets logotyp och en miljöbild. Tack vare en bildklass i iText kunde dessa bildobjekt ges en maximal bredd och höjd vilket tillät användning av bilder med alla tänkbara höjd/bredd förhållanden. Klassen stödjer även import av bilder av många olika format såsom JPEG och PNG. Även PDF-dokument kunde importeras som bilder4 med hjälp av denna klass varför den användes frekvent genom hela katalogens konstruktion. Därmed uppfylldes krav K3 i kravspecifikationen om de bildformat som skulle kunna tas in i verktyget. På baksida (g) samt sida för kontakt- och köpinformation (c - d) placerades textfält för kontaktuppgifter såsom adress och telefonnummer. Då köpinformationen bedömdes kunna vara omfattande i textmängd avsattes en större yta för detta textfält och en högnivåfunktion i iText för att fördela texten över flera kolumner utnyttjades. 2 Standardenheten inom PDF användes som måttenhet vilket motsvarar 72 enheter per tum. Koordinatsystemet för en dokumentsida utgår från nedre vänstra hörnet. I iText finns dock möjlighet att använda exempelvis millimeter som måttenhet istället. 3 I en framtida utveckling ses dock ett behov att ange ordningen för katalogens respektive delar i den externa grafiska mallen. Därav behöver export-klassen struktureras om för att öka dynamiken och på så vis göra detta möjligt. 4 PDF utnyttjades här som ett PostScript-baserat vektorformat 3.3 Programutveckling 35 Figur 3.10. Flödesschema över katalogexport Artiklarna adderades till PDF-dokumentet i en iterativ process (e). Här utnyttjades återigen möjligheten att infoga andra PDF-dokument som bilder i ett nytt dokument. Varje artikel, eller grupp av hophörande artiklar, skapades nämligen först som ett litet komplett PDF-dokument som lagrades i en minnesbuffert. Detta dokument infogades sedan som bild vid en kalkylerad koordinat på sista sidan i huvuddokumentet. Processen började sedan om för nästa artikel, eller grupp av artiklar. Figur 3.11 på sidan 37 visar processen. Som referens visar figur 3.2 på sidan 28 ett resulterande artikel-dokument. 36 Utveckling Till att börja med skapades ett artikel-dokument med en fast bredd och höjd som angetts i den grafiska mallen (e1). I nuläget motsvarar detta bredden av en A4-sida samt en höjd som tillåter fem artiklar, eller grupper av artiklar, att lagom rymmas på en A4-sida. Sannolikheten att höjden för ett artikel-dokument skulle behöva vara dynamisk bedömdes dock som stor eftersom textinnehållet skulle kunna variera kraftigt. I skrivandets stund är dock stöd för detta ännu inte implementerat. Textuella och grafiska komponenter för innevarande artikel eller grupp av artiklar placerades ut vid de relativa koordinater och med de mått som angivits i den grafiska mallen (e2 - e9). Här kunde antalet rader med artikelspecifikationer variera varför rad 2 och uppåt placerades vid kalkylerade koordinater. Då artikel-dokumentet färdigställts skulle detta infogas i huvuddokumentet (e10). Placeringen avgjordes av flera faktorer: Om artikeln var den första på ett nytt kapitel skapades en sidbrytning och artikel-dokumentet placerades högst upp på den nya sidan. Detta gällde även då artikeln inte hörde till ett nytt kapitel, men när föregående sida var helt fylld. Då artikel-dokument skulle placeras under andra artiklar gjordes en enkel koordinatberäkning. Vid varje sidbrytning genomfördes även ett extra moment. En implementerad händelsehanterare triggades varpå artiklar som placerats ut på innevarande sida gavs dess sidnummer. Syftet med detta var att kunna skriva ut sidnummer för artiklarna i det sökbara registret. Om sidbrytning skedde på grund av kapitelbyte spårades och lagrades även föregående kapitels start- och slutsida för innehållsförteckningens skull. Som nämnts ovan placerades artikel-dokumenten ut som bilder vid specifika koordinater på en sida. I iText finns dock en högnivåfunktion för att placera ut objekt i en tabell. Denna funktion sköter själv var på en dokumentsida nästa tabellrad ska infogas samt om en sidbrytning i tabellen behövs. Därav skulle beräkning av koordinater samt kontroll om sidbrytning behövdes inte behövt implementerats. Dock skulle denna metod inneburit att händelsehanteraren inte triggats vid sidbrytning mitt i en tabell varpå spårning av sidnummer för artiklar och innehållsförteckning skulle fallerat. Som sista moment i första iterationen infogades ett register (se åter figur 3.10, f). Här placerades artikelnamn samt tillhörande sidnummer ut i tre kolumner på en sida med hjälp av en högnivåfunktion i iText vilken fördelade text över flera kolumner. Artikelnamnen listades i bokstavsordning. Dubbletter där både artikelnamn samt tillhörande sidnummer överensstämde placerades inte ut. En andra iteration tillfogade innehållsförteckning (h), sidhuvuden och sidfötter (i) till katalogdokumentet. Att innehållsförteckning inte skapades i första iterationen berodde främst på att ett kapitels sidomfattning inte kunde vara känt innan alla artiklar placerats ut. För enkelhets skull allokerades endast en sida för innehållsförteckningen direkt innan första kapitlet och innehållet skalades för att få plats på denna sida. Här adderades objekt i två lager. I det undre lagret lades på förhand skapade färgfält som bilder på kalkylerade koordinater, i det övre lagret lades textfält med kapitelnamn och tillhörande sidreferenser på samma koordinater. Sidnummer för respektive kapitel hämtades från en global datastruktur som skapats under första iterationen och som baserades på fältet artikelgrupp i artikelregistret. Figur 3.5 på sidan 30 visar resultatet. 3.3 Programutveckling Figur 3.11. Flödesschema över generering och infogande av artikeldokument 37 38 Utveckling Till sist adderades sidhuvuden och sidfötter sida för sida till alla sidor utom fram- och baksida. Även här lades på förhand skapade färgfält som bilder i ett undre lager högst upp och längst ner på sidan. Textfält infogades sedan i det övre lagret och dess placering var beroende av innevarande sidnummer: Vänsterjustering för jämna sidor respektive högerjustering för udda sidor. Textinnehåll och val av färgfält var beroende av sidallokering per kapitel som lagrats i den globala datastruktur som nämndes ovan. Resultatet för sidhuvud och sidfot visas i figur 3.4 på sidan 29. Gränssnitt mot användaren Redan innan projektet startades togs beslutet att inte utveckla ett grafiskt gränssnitt mot användaren, men enligt kravspecifikationen skulle vissa användarfunktioner ändå implementeras. I kapitel 3.3.2 tredje avsnittet ovan har möjligheten att ange sökvägar till indata, sökväg för var den färdiga katalogen ska sparas, kontaktuppgifter med mera redan avhandlats. Däremot behövde funktionalitet för att ge varningar till användaren enligt krav K11-K12 implementeras. Det handlade om fall då sökvägar till indata visade sig vara felaktiga eller då en katalogfil med angiven sökväg redan existerade. I det första fallet användes felhantering inbyggd i Java API för att hantera inmatningsfel. Här gjordes ett tillägg att visa en dialogruta för användaren som gav upplysning om felet samt avbryta exekveringen, se figur 3.12 nedan. I det andra fallet kontrollerades om den fil som angetts i inställningsfilen redan existerade. Även här genererades en dialogruta där användaren hade möjlighet att avbryta exekveringen, skriva över den befintliga filen eller via dialogrutan ange ett nytt filnamn, se figur 3.13 nedan. Båda funktionaliteterna implementerades i import-klasserna som beskrevs tidigare. Figur 3.12. Dialogruta vid fel sökväg till artikelregister Figur 3.13. Dialogruta då katalogfil redan existerar 3.3 Programutveckling 39 Som sista moment i utvecklingen skulle krav K8-K9 om hur verktyget skulle exekveras uppfyllas. För att göra verktyget exekverbart via en fil valdes att utnyttja exportfunktioner inbyggda i utvecklingsmiljön Eclipse. Alla skapade klasser och nödvändiga Java-bibliotek packades till en exekverbar JAR-fil (Java ARchive). Externa resurser såsom bilder, artikelregister och inställningsfiler behövde dock ligga i en mapp utanför detta arkiv för att vara åtkomliga och manipulerbara för användaren av verktyget. En nackdel med denna metod var dock att krav K8 om systemförsutsättningar där verktyget skulle användas inte helt kunde uppfyllas. Enligt kravet behövde systemet inte inneha någon JRE (Java Runtime Environment) vilket är en förutsättning för att kunna exekvera en JAR-fil. Det finns dock lösningar för att komma runt detta problem. Ett exempel är att bifoga en installationsfil med verktyget vilken vid behov installerar nödvändig version av JRE via ett skript på det lokala systemet första gången verktyget exekveras. Försök att implementera detta gjordes dock inte innan projektet avslutades. Kapitel 4 Resultat och diskussion Detta projekt gick ut på att skapa ett verktyg för att enkelt och automatiskt skapa kataloger i PDF-format utifrån ett på förhand känt artikelregister. Syftet med verktyget var att spara tid och resurser vid katalogproduktion, särskilt för småföretagare där tid och resurser kan vara en bristvara. Verktyget skulle även syfta till att minska risken för att infoga fel i katalogmaterialet. Målet med projektet skulle vara uppnått när dessa krav uppfyllts. I detta kapitel utreds hur väl syfte och mål uppnåtts samt lämplig vidareutveckling av verktyget i framtiden. 4.1 Utvärdering av verktyget Under projektets gång har ett kataloggenereringsverktyg utvecklats i Java med funktioner enligt den kravspecifikation (se bilaga 1) som tagits fram på förhand. Då utvecklingen var klar genomfördes ett funktionstest för att testa om respektive krav uppfyllts. Verktyget kan nu importera ett artikelregister i formatet MS Excel med de artikeldata som specificerats, exempelvis artikelnamn, pris och sökväg till produktbild. Ett antagande gjordes att artikelregistret exporterats från ekonomisystemet Visma med viss förutbestämd kolumnordning vilket utvecklingen baserats på. Även om stor tidsbesparing och minskad felrisk uppnås på detta vis, krävs dock viss manipulering av registret fortfarande såsom att manuellt ange sökväg till produktbilden. Här ses även ett behov att bygga in stöd för en större variation i ett Excel-registers utformning. Detta skulle exempelvis kunna uppnås genom att användaren anger kolumnordningen i en inställningsfil, förslagsvis den XML-fil där alla andra fördefinierade värden anges. Verktyget kan importera produktbilder i formaten JPEG, PNG och i vektorbaserat PDFformat, samt skala dem till en angiven storlek. Tack vare bild-klassen i iText fungerar detta på ett bra sätt och dessutom accepteras många fler bildformat såsom GIF och TIFF. Ansvaret för kvalitet på produktbilderna överlåts däremot till användaren. Som grafisk mall används ett XML-dokument där exempelvis sökväg till företagslogotyp samt koordinater för textuella och grafiska objekt angetts. Även informationsdata såsom telefonnummer och adress anges i detta dokument. Här ses en möjlighet att ange många fler dynamiska indata till programmet. Som nämndes ovan skulle detta exempelvis kunna vara kolumnordningen i artikelregistret, men det skulle även kunna vara ordningen på katalogens beståndsdelar eller hur artiklar ska sorteras inom ett kapitel med mera. Detta för att öka användarens inflytande över katalogens utformning. Dock ses en viss nackdel med att ange indata direkt i ett XML-dokument. För en ny användare kräver det att alla element redan 41 42 Resultat och diskussion existerar i dokumentet och endast behöver editeras med andra koordinater, sökvägar och liknande. Det kan inte krävas av användaren att denne ska ha tillräcklig kunskap om XMLstrukturen för att kunna ange nya element. Utöver detta bedöms risken att infoga fel i det befintliga XML-dokumentet som väldigt stor. Något så enkelt som att råka ta bort ett element eller skriva in ett decimalt värde med kommatecken istället för punkt skulle orsaka exekveringsproblem. Ett sätt att minska risken för editeringsfel skulle vara att skapa en DTD till XML-dokumentet i vilken XML-strukturen definieras. För att utnyttja DTD:n skulle även validering av denna behöva implementeras i verktyget. På så vis skulle användaren kunna få varningar när XML-dokumentet inte är rätt utformat. Ett grafiskt användargränssnitt skulle dock markant öka användbarheten av verktyget samt minska felrisken. Detta tas upp i avsnitt 4.3 - Vidareutveckling. Vad gäller export framställer nu verktyget ett PDF-dokument i A4-format vilket innehåller pärm, innehållsförteckning, kontakt- och köpinformation, register samt en produktförteckning innehållande allt det data som artikelregistret rymmer. Utformningen bedöms som tillräckligt generell för att vara applicerbar på produktsortiment av vitt skilda typer. Detta eftersom en färdig katalog innehåller de beståndsdelar som under förstudien visats ingå i de flesta produktkataloger på marknaden samt att grafiska element har hållits neutrala i sin utformning. Även kravet om objektsseparering är uppfyllt. Enskilda objekt går att markera i PDF-dokumentet och på så vis finns möjligheten att manuellt editera dokumentet i efterhand. Till sist har användningskraven testats. Användaren kan i inställningsfilen ange sökväg till artikelregister, filnamn för den färdiga katalogen, kontaktinformation med mera. Verktyget kan köras via en exekverbar JAR-fil samt ge varningar när sökvägarna ovan är felaktiga eller en katalog med angivet filnamn redan existerar. Det enda krav som inte uppfyllts helt är det om den datormiljö där verktyget ska exekveras. Som nämnts i kapitlet om utveckling krävs tillgång till JRE eftersom verktyget i nuläget exekveras som JAR-fil. En lösning som avhandlades var att inkludera nödvändig version av JRE med distributionen, men det finns även andra alternativ [27]. Ett sätt är använda en så kallad Ahead-Of-Time (AOT) kompilator. Denna kompilerar Java-koden och skapar en exekverbar fil vilken är anpassad mot den plattform där verktyget ska köras. Detta kräver dock tillgång till ett verktyg för AOT Java Compilation samt att det skapar ett plattformsberoende vilket motverkar syftet med Java - att vara plattformsoberoende. Som komplement till kraven om användning skulle även ett användartest kunnat utföras där verktyget utvärderades i skarpt läge. Detta skulle ha synliggjort fel som ännu inte hanteras av verktyget, samt gett en uppfattning om hur användaren upplever verktyget. Utifrån ett sådant test skulle säkerligen fler förbättringar av verktyget kunnat göras. För framtida utveckling av verktyget är detta något som rekommenderas. 4.2 Resultat Slutsatsen är att syften och mål med projektet i det stora hela har uppnåtts. En studie i hur ett kataloggenereringsverktyg kunde utformas har genomförts. Därefter har ett sådant verktyg skapats som tillåter stora resursbesparingar vid katalogproduktion, främst vad gäller tid. Risken för att infoga fel minskas betydligt då ett artikelregister innehållande data som exporterats direkt från ett ekonomisystem används samt att verktyget medför stor minskning vad gäller manuell editering av katalogmaterialet. Alla krav, förutom krav K8 om datormiljö, har uppfyllts. 4.3 Vidareutveckling 4.3 43 Vidareutveckling Vid eventuell vidareutveckling av verktyget ses många möjligheter och behov som kan täckas in. Inom ramarna för examensarbetet ingick inte att utveckla ett grafiskt användargränssnitt (se avsnitt 1.3). Om ett sådant togs fram skulle användaren kunna ange data i exempelvis ett mer formulärliknande gränssnitt, välja bland fördefinierade data i rullister eller till och med välja bland flera layout-mallar utifrån grafiska representationer av dessa. Ett XML-dokument kan i detta läge fortfarande användas för lagring av indata, men användaren slipper manipulera XML-dokumentet direkt. Användbarheten ökar och risken för fel minskar. Ett annat sätt att öka användbarheten av verktyget är att implementera stöd för olika typer av artikeldatabaser såsom MySQL, Oracle samt MS Access. Under förstudien nämndes ODBC-brygga som i ett sådant läge skulle kunna fungera som nav mellan aktuell databas och applikationen. Här borde även användaren ges möjlighet att i användargränssnittet mappa upp de artikelfält i databasen som ska användas. På så vis ökas även flexibiliteten med verktyget. Flexibilitet i utformningen av den färdiga katalogen kan även uppnås genom att ett flertal typer av layout-mallar skapas, om inte annat för att tillmötesgå olika tycke och smak. Här kan diskuteras om dessa mallar endast bör utformas av utvecklare av verktyget, eller om användarna själva ska ges möjlighet att skapa egna mallar. Det senare alternativet skulle förmodligen innebära utveckling av ett mer avancerat gränssnitt där användaren grafiskt kan skapa och manipulera sådana mallar. I nuläget lagras en layout-mall som XML-data, men i läget av grafisk editering skulle en mall även kunna lagras som ifyllbara PDF-formulär. Stöd för formulär i PDF-format ingår i PDF-standarden. Vad gäller innehållet i den färdiga produktkatalogen ses ett flertal implementationsmöjligheter. Några exempel listas nedan: Möjligheten att exkludera artiklar i artikelregistret vid export till katalog. Möjligheten att ange vilka artiklar som är nyheter för säsongen. Möjligheten att endast välja ut en eller flera artikelgrupper att publicera. Tillåta mer än en produktbild per artikel eller gruppering av artiklar. Möjligheten att infoga titelsidor inför varje kapitel i katalogen. Möjligheten att skapa en katalog med en separat prislista. Detta kan vara användbart då ett produktsortiment är relativt konstant, men priser ändras med mycket högre frekvens. Stöd för olika pappersformat utöver A4. Anpassa katalogen för tryck med exempelvis ett jämnt antal sidor i dokumentet, använda färgsystemet CMYK, bedöma om upplösningen är tillräckligt hög på produktbilder, utfall med mera. 44 Resultat och diskussion Till sist finns en vision att utveckla verktyget med ett webb-gränssnitt där användaren laddar upp eller länkar till artikeldatabas och katalogmaterial, men själva exekveringen sker på server-nivå. Användare skulle kunna välja mellan flertalet layout-mallar vilka uppdaterades med kontinuerliga nytillskott, kanske till och med erbjudas möjligheten att skapa och editera egna. Detta skulle dock kräva en radikal förändring både av gränssättande krav och implementationen hittills. Fördelen skulle dock vara att tillgängligheten av verktyget ökar markant samt att plattformsberoendet och behovet av distribution elimineras. Men det ligger många utvecklingstimmar framåt i tiden... Litteraturförteckning [1] Apache POI - the Java API for Microsoft Documents. http://poi.apache.org/ , Juli 2012. [2] Document Object Model (DOM). http://www.w3.org/DOM/ , December 2012. [3] EasyCatalog Features. http://www.65bit.com/products/easycatalog/features/features.shtm , Juni 2012. [4] GiBi sPrint. http://extensions.gibilogic.com/index.php?option=com_zoo&task=item&item_id=1 , Oktober 2012. [5] ISO Standard - PDF 32000-1:2008. http://wwwimages.adobe.com/www.adobe.com/content/dam/Adobe/en/devnet/pdf/pdfs /PDF32000_2008.pdf , September 2012. [6] iText, a Free Java-PDF library 5.3.0 API. http://api.itextpdf.com/itext/ , Oktober 2012. [7] iText and the Affero General Public License. http://itextpdf.com/terms-of-use/agpl.php , April 2012. [8] Java Excel API - A Java API to read, write, and modify Excel spreadsheets. http://jexcelapi.sourceforge.net/ , April 2012. [9] JDOM Mission. http://www.jdom.org/mission/index.html , November 2012. [10] License for font Quicksand. http://www.fontsquirrel.com/license/Quicksand , November 2012. [11] Nevotex - Om Företaget. http://www.nevotex.se/en-us/svenska/omföretaget.aspx , Oktober 2012. [12] PDF catalog - Export products and Categories in PDF. http://www.magazento.com/english/pdf-export , September 2012. [13] PDF Catalog Creator. http://www.hanmingsoft.com/products/catalog2pdf/ , Oktober 2012. [14] Wikipedia - Adobe InDesign. http://en.wikipedia.org/wiki/Adobe_InDesign , Oktober 2012. 45 46 Litteraturförteckning [15] Wikipedia - Biltema. http://sv.wikipedia.org/wiki/Biltema , Oktober 2012. [16] Wikipedia - Document Object Model. http://en.wikipedia.org/wiki/Document_Object_Model , December 2012. [17] Wikipedia - Innehållshanteringssystem. http://sv.wikipedia.org/wiki/Innehållshanteringssystem , Oktober 2012. [18] Wikipedia - Java API for XML Processing. http://en.wikipedia.org/wiki/JAXP , November 2012. [19] Wikipedia - Lista över webbpubliceringssystem. http://sv.wikipedia.org/wiki/Lista_över_webbpubliceringssystem , Oktober 2012. [20] Wikipedia - Microsoft Publisher. http://en.wikipedia.org/wiki/Microsoft_Publisher , Oktober 2012. [21] Wikipedia - ODBC. http://en.wikipedia.org/wiki/ODBC , Oktober 2012. [22] Wikipedia - Portable Document Format. http://en.wikipedia.org/wiki/Portable_Document_Format , September 2012. [23] Wikipedia - PostScript. http://en.wikipedia.org/wiki/PostScript , September 2012. [24] Wikipedia - Simple API for XML. http://en.wikipedia.org/wiki/Simple_API_for_XML , November 2012. [25] Wikipedia - XML. http://en.wikipedia.org/wiki/XML , Maj 2012. [26] Erdman, Paul: Database to InDesign. http://www.creativeprogression.com/database-to-indesign/ , Maj 2012. [27] Leskov, Dmitry: Convert Java to EXE. http://www.excelsior-usa.com/articles/java-to-exe.html , Juli 2012. [28] Lowagie, Bruno: iText in Action. Manning Publications Co, 2011, ISBN 9781935182610. [29] Rozenberg, Bert: VirtueMart Catalog. http://www.mrose.nl/virtuemartcatalog , Oktober 2012. [30] White, Terry: Use Data Merge to build personalized documents. http://www.adobe.com/designcenter-archive/indesign/articles/indcs2at_datamerge.html , Oktober 2012. Bilaga 1 Kravspeci kation Skallkrav Funktionella krav K1: Verktyget skall kunna ta in ett artikelregister producerat i minst ett av formaten möjliga i MS Excel. K2: Verktyget skall kunna ta in följande artikeldata i deras grundkonfiguration: Artikelnummer Artikelnamn Artikelgrupp Artikelinformation Förpackningsmängd Enhet Pris per enhet Bild som länk till fil och/eller bilddata K3: Verktyget skall kunna ta in bilder av formaten JPEG, PNG och/eller något PostScriptbaserat vektorformat. K4: Verktyget skall kunna skala bilder till angiven höjd och bredd. K5: För grafisk layoutkomponering skall verktyget vid körning utnyttja en eller flera fördefinierade mallar. Dessa mallar skall vara grafiska eller textuella till karaktären. (forts.) 47 48 Kravspeci kation K6: Verktyget skall vid körning framställa en katalog i PDF-format i storlek A4 innehållande följande: Artiklar med tillhörande data ingående i importerat artikelregister. Artiklarna skall vara sorterade i artikelgruppsordning. Fram- och baksida Innehållsförteckning Kontaktinformation Köpinformation Register K7: PDF-katalogen skall vara objektsseparerad1 . Användningskrav K8: Verktyget skall gå att använda på en laptop med följande egenskaper: Operativsystem Windows XP eller senare. Adobe Reader MS Excel Åtkomst mot Internet upp- eller nedkopplad. K9: Verktyget skall kunna köras som exekverbar fil. K10: Verktyget skall efter programstart kunna konfigureras via en dialogruta eller en inställningsfil i vilka användaren kan ange följande: Sökväg till befintligt artikelregister som skall användas vid katalogframställningen. Filnamn och sökväg där katalogen skall läggas. Sökväg till framsidesbild. Kontaktinformation. Sökväg till textfil innehållande köpinformation. K11: Verktyget skall ge varning till användaren när sökvägar till artikelregister, framsidesbild eller köpinformationsfil saknas. K12: Verktyget skall kunna ge varning till användaren när katalog med angivet filnamn och sökväg redan existerar med valmöjlighet att avbryta eller fortsätta. Vid valet att fortsätta skall den tidigare katalog-filen skrivas över. 1 Med objektsseparerad menas att varje bild- och textobjekt i det resulterande PDF-dokumentet ska gå att markera var för sig. Detta i syfte att kunna editera dokumentet manuellt i efterhand.