Kontaktinfo

[olajoh1]

Rubriksättningen i dagens kontaktruta har två nivåer. Saknas nu, jmf nedan.

http://www.test.malmo.se/Medborgare/Kultur--fritid/Foreningsliv/Foreningsavdelningen.html http://www.malmo.se/Medborgare/Idrott--fritid/Foreningsliv/Foreningsavdelningen.html

@jesperbylund

[martent]

Vi valde en nivå i designfasen och jobbade igenom det så vi får ta tillbaka det till ett par nya iterationer för att föra ändringar om det ska bli bättre. Ska vi strukturera kontaktrutan om så får vi fundera igenom alternativen, vad som ska vara rubriker i de olika fallen där det finns en kontakt respektive flera kontakter.

I fallet med en singulär kontakt som det oftast är så blir det tydligast med h2:or för de olika kontaktmetoderna. I de fall där det finns flera kontakter blir det kanske tydligast att varje kontakt är en h2:a medan kontaktmetoderna är de diskretare h3:orna. Men att metoderna blir h3:or i alla de fall där det bara finns en kontakt är lite synd. Detta påverkar även sökmotorers tolkning av adresskorten eftersom de går på vCard/hCard-standarden för att lista ut semantiken i kontakten.

[martent]

Jag gör skisser i prototypen på en respektive tre kontakter.

[martent]

Ny design och funktion är ute i prototypen för:

• Enskilda kontakter
• Flera kontakter
• Flera kontakter med stadsområdesväljare

Stadsområdesväljaren laddar inte om sidan utan laddar kontakterna omedelbart inline. Formuläret laddar inte heller om sidan utan skickar in via Ajax. Just nu ser man succé-meddelandet men det ska vara samma för formulär med valideringsmeddelande ("Du måste välja ärendetyp") och felmeddelanden.

HTML-koden är kraftigt optimerad för att minska laddnings- och renderingstider.

Lösningen ska vara, och måste vara, bakåtkompatibel med första lösningen i WAG 4 eftersom andra tjänster använder markup-struktur och stilsättning vi specade där. WAG 4 får uppdateras med den nya stilsättningen men den gamla måste fortfarande fungera.

Jag avvaktar med tekniska instruktioner till @rbolton479 tills design och funktion är itererad.

[olajoh1]

Designen tydlig och klar nu. Funderar på stadsdelsväljaren. När jag väljer att skriva in en adress visas nu auto suggest gatuadresser med nummer och stadsområde inom parantes. En förändring som jag inte känner igen.

[martent]

Allt som är bättre med kontaktrutan är oigenkännligt :imp: Att inte sidan laddas om och du hamnar längst upp är också nått du inte känner igen. Tanken är att man visuellt får kopplingen mellan adress och stadsområde redan innan man väljer. Men det är enkelt att ta bort.

SBK kommer att utöka sitt API så att vi får grupperade gatunummer senare i veckan. "Storgatan" ger bara en post eftersom hela ligger i Norr medan Amiralsgatan ger flera intervall eftersom den går genom flera stadsområden. Typ

Amiralsgatan 1-23
Amiralsgatan 27-89

[martent]

Implementationsinstruktioner

Här är en summering av ändringarna. Det är dels stiländringar som till viss del påverkar markup men även interaktionsändringar för att sidan inte ska laddas om. Detta beskrivs nedan. Jag har försökt utgå från att du ska kunna utnyttja befintlig logik i portleten och servleten.

Stilsättning är ändrad. Denna är deployad i "Global Assets" staging som www.test.malmo.se pekar mot. Denna stilsättning hämtas alltså in automatiskt. Kolla med @Esset och @hryd om det gick för snabbt när jag förklarade detta i måndags. I nuvarande versionen av portleten (eller om den lagts i sitevision_assets) ligger nog en del ad-hoc-stilsättning som krävdes i 4.0. Denna ska inte nya versionen.

Markupen är ändrad för att matcha stilsättningen. Detta gäller alla tre former av kontaktrutan: en enstaka kontakt, flera kontakter och flera kontakter med stadsområdesväljare. Det är samma markup för Kontaktkorten för alla tre varianter. Du ser det i prototypen på:

http://webapps07.malmo.se/juni2014/body-copy-2/ http://webapps07.malmo.se/juni2014/body-copy-18/ http://webapps07.malmo.se/juni2014/body-copy-19/

Skillnaden mellan de tre är att Stadsdelsväljaren har classen multi-district i aside-elementet men de två andra inte:

<aside class="contact-us multi-district basic">
<aside class="contact-us basic">

Kontaktformuläret, som i stort sett är identiskt när de finns flera kontakter eller för stadsområdesväljaren, förekommer nu endast en gång i koden, som en "template" som ett JavaScript (coffescript) clonar och använder för alla kontakter. För symmetrins skull används samma metod när det endast finns en kontakt. Koden för detta har jag skrivit och ni får flytta den från prototypen till sitevision_assets. @Esset och @hryd vet hur detta görs. Det gäller följande rader som ska ersätta nuvarande JavaScriptet som Kontaktrutan använder:

https://github.com/malmostad/external-prototype/blob/master/_includes/coffeescripts/contact.coffee#L9-L100

Mindre justeringar kan eventullt behövas göras men jag har utgått från nuvarande portleten genom att action och värdet för contactid som i nvarande portlet sätts i varje <form> nu sätts som data--attribut i länken som öppnar kontaktforumläret. JavaScriptet hämtar värdena därifrån när den clonar formuläret. Länken ska se ut så här för första kontakten om den har contactid=0:

<div class="write-to-us" data-contact-id="0" data-action="/4.427bf15412207bac3c980003373.html.portletaction?sv.url=12.228b8e2313f816262743382"><a href="/">Skriv till oss</a></div>

data-action är värdet som tidigare satts i <form action="">. data-contact-id är värdet som tidigare satts som en <input type="hidden">.

Ett problem idag är att när man väljer stadsområde så laddas sidan om och användaren tappar kontexten. Jag har gjort en ny JavaScript-baserad lösning för detta:

• Alla kontakter ska finnas med i koden på sidan när den laddas (se prototypen ovan). JavaScriptet visar endast vald stadsdel, eller ingen, om stadsdel inte är vald.
• Adress-sök med autocomplet får nu mot ett JSON-API för gator och stadsdelar så Oracle-kopplingen i portleten behövs inte längre. Detta är implementerat i ovanstående JavaScript.
• JavaScriptet sätter också cookien client side, så det behöver inte göras i portleten.

Formuläret POST:as till portleten med Ajax istället för en page reload. Kod för detta finns i JavaScriptet. Ändra koden i JavaScriptet vid det två FIXME-kommentererna när ni lyfter den från prototypen. Det är samma värden som servleten får som tidigare.

Vad servleten måste göra när formulräet POST:as är att, om validering går igenom, returnera en HTML-fragment med nuvarande success-meddelande:

<div class="success">Ditt meddelande har skickats till [epos-tadress].</div>

Om formuläret inte validerar (meddelande t.ex. saknas), ska servleten returner formuläret med nuvarande valideringsmeddelande.

Det är alltså samma markup som servleten returnerar som idag, fast endast formuläret eller success-meddelandet, inte en hel HTML-sida. JavaScriptet injectar fragmentet på sidan. Lägg märke till att formuläret med validerings-meddelande måste vara fullständigt med action och contactid, här sker ingen JavaScript-manipulering som det gör via page load.

@rbolton479, ring mig om du vill diskutera eller ha ytterligare förklaringar. @Esset och @hryd har också svar på frågor kring relationen mellan Kontaktrutan och SV vad gäller CSS och JavaScript och miljöerna i allmänhet.

[rbolton479]

kommer läsa ordentligt tills imorgon och återkommer om jag har frågor

[rbolton479]

Inte helt säkert om det går att skicka tillbaks bara en HTML fragment. Det är någonting som har försökt att fixa i mina nuvarande portlets men inte hittat en lösning. The underlying system always seems to wrap up the fragment with an entire HTML header and body. Min nyaste portlet har jag lagt svaret i en div som inte visas, sedan har jag tagit ut de fragment jag vill har med jquery.replaceWith("theDivIWant") sedan tar jag bort allt efteråt.

[martent]

IIRC, you can render a SV portlet either wrapped in html and body tags or as a standalone fragment or even as plain text without the markup. This indicate that that assumption might be true:

http://help.sitevision.se/SiteVision_3_0/809.html#h-Portletrendering

[rbolton479]

thanks, that will help mee enormously :-)

[rbolton479]

hej mårten, Fritext fält verkar inte var med i prototypen. Det finns massor sidor med det. Här är en http://www.test.malmo.se/press

[martent]

Put the text inside a p element right after the h2 heading. I will add styling for it tomorrow.

[rbolton479]

will do

[rbolton479]

I've only just noticed that 'lämna synpunkter' wasnt on the original portlet and you haven't mentioned anything about it in this version either, can you explain?

[martent]

"Lämna synpunkter" is only in the prototype so far. Not scheduled for implementation yet.

[martent]

Styling deployed in global assets staging. See example on e.g.:

http://webapps07.malmo.se/juni2014/body-copy-2/

Use the same markup in multiple contacts and district selector contacts, i.e. just a p element for the free text.

[rbolton479]

yeah i can do that, feels a bit hacky though, cos 'vcards' are displayed in a loop per contact but it seems like there is only one fritext field

[martent]

You’re right. Put it directly under <h1>Kontakta oss</h1>.

[martent]

Current styling should work.

[rbolton479]

cool, i'll revert my hack :-)

[rbolton479]

i've now started with the stadsväljeren and it seems that if you want all the districts contact details displayed on the page from the beginning I will need to add start using the new API. I've read a little about it on github and was wondering if I need to contact them to get a login token or do you have one that I should be using instead

[martent]

This is two different releases. This ticket is about 4.2 still using the LDAP as data source. There is no new info beings displayed compared to the solution in production now, just different rendering.

When 4.2 is stable you can start with the the REST API as the data source. I manage the tokens for that API.

[rbolton479]

Ok, I wasnt a 100% percent sure if that was the case, over the phone is much harder to understand the skånsk accent, i'm sure it will get better.

[rbolton479]

I think I thought because you were using it in your prototypes that I should use it too

[rbolton479]

Hi Mårten, seems that I dont have permission to push my changes, can you help?

[rbolton479]

I can see that my email address is set correctly

[martent]

Your permissions got lost when I removed and recreated the repo. Restored it now.

[rbolton479]

latest changes pushed to repo, thanks mårten for fixing.

[rbolton479]

Hi mårten, i've been trying to work out why the district selector javascript doesnt work, anyway, after checking that all the names, classes and Id's were correct I came to the conclusion that it must be something wierd in the coffee script. So what I decided to do was take the application.js from the prototypes and copy it over to local assets exploded directory on the test server, and low and behold, it all seems to work nicely. Then i proceeded to compare the prototype javascript and the compiled javascript from sitevision assets and they appear quite vastly different and I'm left feeling very confused. Shall I get henrik and Simon to help here, or would you prefer to figure it out yourself, it's certainly beyond my current skillset.

[martent]

The prototype coffee/js should be different from the one in sitevsions_assets. The working process we have had and have is that I write some code already in the prototype and @Esset and @hryd have reused it for the sitevision_assets. Sometimes they have altered it afterwords on later requirements or for SV specific selectors etc. And some code is written by them from scratch when no prototyping was made for simple requirements that didn't include a visual iteration. This means that in some cases, like the new coffee code for the contact portlet, the prototype code can be reused as a start but the sitevision_assets or the portlet repo will never be in sync with the prototype. So a diff is natural.

In this particular case, the coffee has not been move from the prototype to sitevision_assets or the portlet code as far as I can see, compare those two:

https://github.com/malmostad/external-prototype/blob/master/_includes/coffeescripts/contact.coffee https://github.com/malmostad/sitevision_assets/blob/master/src/javascripts/contact_us.coffee

[martent]

Another question, is this code still used in the the portlet: https://github.com/malmostad/sv-contact-portlet/tree/master/src/resources/script

jQuery 1.11.1 is bundled in the Global Assets v4 (v.1.3 above is ancient). A modern version of autocomplete is also bundled in Global Assets. Or is the code above only used in the admin interface? If so, that one would include Global Assets as well. But postpone that change to after release 4.2 if it still works so we don't get a scope creep now.

[rbolton479]

I think we might be misunderstanding each other mårten. I moved the code from the coffee script into sitevision assets and built it and then installed the jar file on the test server like you said/wrote. Then when I tested it, I found it wasnt working for district selector. I have never used coffee scripts before but I thought I would at least try to see if I could find out what the problem is. I couldnt see anything visually wrong with the script (although i'm not entirely sure what I was looking for) so I thought, why not copy the prototype to the test server and see if that works and of course it did. So it became clear to me that what ever was in the coffee script was wrong and I guess just wasnt sure how to move forward being that I've never used coffee before but I will talk to henrik and get him to help.

[rbolton479]

In answer to your other question, There is a velocity header file which is used by a number of the config views, one of which is 'contactBoxForm.vm' for example

[martent]

You have not moved the new coffeescript from the prototype to sitevision_assets, it is not in any of those branches.

To be able to help, I need a at least a description of what goes wrong, some error messages or somethings on the test server i can debug. It is not possible to assist based on the information that "it doesn't work".

[rbolton479]

Good morning, Just so you know that I know, there is a bug with the contact info when somebody successfully sends an email. The problem is that the form doesnt get hidden afterwards. I've already discussed a solution with simon and I'll be implementing it sometime this morning but for now i'm going to the doctor.

[rbolton479]

now it's fixed and checked in

[martent]

Ok, I close this implementation ticket. If bugs are found, the will be filed in new tickets, one for each.