Den här webbplatsen använder kakor (cookies) för att spåra trafik som delas med Google Analytics och andra parter. Dessa parter kan kombinera denna information med den som de samlat in genom din användning av deras tjänster. Du samtycker till våra kakor genom att fortsätta använda denna webbplats.

Stratum 3

Stratum 3 - möte 3

Initialt fokus på Cloudinary som tjänst för bildhantering - vad behöver vi ha för konto? Börja med gratiskonto och se när vi slår i taket. Flera typer av uppgradering av konto finns. Hur skall vi hantera stora bilder? Kan vi “resampla” genom Cloudinarys api? Hur väl fungerar integrationen med Keystone? Får vår kommunikatör det som behövs? Här borde vi sitta med henne för att mer i detalj avgöra hur hon arbetar. Vi skulle kunna åta oss att importerar hennes nuvarande bilder med taggar och titlar. Är det görbart?

När vi ändå talar om import - är det möjligt att importera sidor i största allmänhet? Då kanske vi kan flytta hela gamla webbplatsen på ett automatiserat sätt. Under tiden som vi ändå implementerar de första sidorna kan vi undesöka hur svårt det skulle vara.

Vad gäller mallar så föreslås att vi utgår från de ursprungliga skisserna från Ibiz. Härifrån avvaktar vi resultatet från Tonsillregistrets genomgång av sin befintliga och nya webbplats med vår kommunikatör. En snarlik fråga är: skall vi ha med registerbegreppet i Keystone och arbeta med en databas eller skall vi satsa på flera Keystone-instanser?

Teknikval i allmänhet och stack på klientsidan i synnerhet. Keystones admingränssnitt är numera implementerat med Facebooks React. Föreslår att vi använder React då det finns med i Keystone. Keystone-projektet och dess community kommer troligen använda det än mer, då Jed Watson visat vägen. Läs också om hans argument för att använda React. Däremot kanske vi borde välja bort JSX på grund av förkompilering och jobbig syntax? Angular JS som alternativ skulle kunna vara intressant då de också har komponenttänkandet i fokus (via Directives) och att det används i nya NDR.

Handlebars använder vi som “template engine” då känns mest “klassisk”. Dessutom kan Keystones generator producera vyer på detta sätt “out-of-the-box”.

IISNode och övrig IIS-integration. Hur väl fungerar det? Tänker då på hantering av certifikat, tvingande HTTPS, loggning och annat. Kanske bäst att förpassa så mycket som möjligt till Node.js och Keystone.

Vår Github-organisation:

Registercentrum Västra Götaland

Stratum 3 - möte 2

Det finns ett antal saker som vi borde få gjort, eller åtminstone påbörja innan vi dyker allt för djupt ner i Keystone JS:

A. Uppgradering till ExtJS 5.1. Här är det framför allt diagramhanteringen som blir annorlunda då vi nu satsar på den bättre och modernare “Sencha Charts”. Vad gäller själva Stratum (registreringsapplikation plus portal) samt SFRs registreringsapplikation så är det inte så mycket arbete. Vi har redan uppgraderat till ExtJS 5.0 så det mesta arbetet är taget. Däremot så innebär det en hel del för våra widgets eftersom just diagramhanteringen är ganska annorlunda. I ExtJS 5.0 så fungerade vare sig nya “Sencha Charts” eller gamla “ExtJS 4 Legacy Charts” tillräckligt bra för att vi skulle kunna växla, vilket är främsta skälet till att vi ligger kvar på v4.2.2. “Sencha Charts” fungerar under IE8, det har vi testat idag. OBS! byt sidbredd till 960px (nu 920px).

B. Byte av tema till “Crisp” (eller “Crisp Touch” — åldersfördelningen kan tala för den sistnämnda, se nedan). Detta kan låta enkelt men det är rätt mycket CSS-hack som tillkommit genom åren plus att en del vyer inte alls är gjorda för att kunna skalas på ett tillfredsställande sätt. Inte minst kan jag misstänka att det blir en del arbete i SFRs registreringsapplikation, där fler antaganden gjorts om typsnitt och grad.

Åldersfördelning bland registrerande användare i Stratum

C. Direct api:et behöver elimineras och gå upp i övrigt REST api. Hela Stratums registreringsapplikation behöver kapslas in api också. Oavsett lösning på detaljproblem är det viktigt för att lättare kunna identifiera vad som är “special” för SFR att särskilja det i “FractureApplication.js” (som tidigare), “FractureManagement.cs”, där vi lägger allt som är noterat “//SFR Exclusive” i C#-koden, och SFR-specifik CSS “Default.css” till “Fracture.css”.

Bildbank med Cloudinary kan vi titta på tidigt. Strategiskt då det gynnar vår webbredaktör. Kika på att flytta över hennes befintliga attribut på bilder plus själva bilderna. Hur funkar det? Kan vi bygga in den funktionaliteten i vårt CMS någorlunda enkelt?

Registercentrum Västra Götaland

Stratum 3 - möte 1

ExtJS hela vägen?

Fördelar

  • Ett ramverk som innehåller (i princip) allt vi behöver!
  • Vi kan det rätt väl.

Nackdelar

Alternativ utan ExtJS hela vägen?

  • Keystone JS som CMS. Alternativ till Keystone finns också, Apostrophe (+ för WYSIWYG), Ghost. Dessa två är relativt etablerade. Zero, PencilBlue är mer nyetablerade men ser spännande ut. En fördel med Keystone är att det är många som följer och bidrar. Samtliga ovan är Node.js-baserade. Körs lämpligen under iisnode på befintlig IIS-server. Hur bra fungerar det? Förmodligen bra eftersom Microsoft Azure använder det.
  • Registreringsapplikationen får göras om som “widget”, eller åtminstone bli api-driven till 100%.
  • Ramverk på klientsidan? React skulle nog passa fint men vi får ta reda på framöver vad vi behöver.

Annat värt att notera

  • Direct-api:et försvinner och ersätts med REST! Dock får vi inte ta bort stödet för SFRs applikation.
  • Widgets till GitHub! Strategi? Struktur? Arbetsmetoder?
  • ExtJS för Widgets nödvändigt. Det är trots allt det mest heltäckande ramverket för den typen av grafisk återkoppling. Dessutom vore det väldigt mycket arbete att byta ut.

Strategi

  • Viktigt att avgöra om vi bygger för hela RC eller enbart Stratum?
  • Om vi bygger för RC också är det viktigt att vi intervjuar och kartlägger Charlottas arbetssätt. Vad är det som fungerar dåligt idag? Vad fungerar bra? Vad är superviktigt?
  • Bygg i så fall ny webbplats vid sidan av och presentera när det är någorlunda färdigt. Då blir det väsentligt att CMS-funktionerna erbjuder något nytt. Måste också se ut som RCs nuvarande webbplats.
  • Viktigt att våra användare får en möjlighet att se vad som är på gång när det finns något vettigt att visa.
  • Sencha Touch droppas helt. Eftersom vi bygger en responsiv webbplats skall inte sådan teknik behövas. Detta innebär att en ny registreringsapplikation för PROM, eller rättare sagt en “en-fråga-per-sida”-applikation tas fram som en widget. Gamla “missbenämnda” MetaBrowser görs också om och den funktionaliteten (och mer därtill) läggs upp som en widget.

Att också ersätta den här bloggen med en som finns i Keystone känns lämpligt- :-)

Registercentrum Västra Götaland