Posts Tagged "GUI"

Time-coded email service

Posted by David on Aug 6, 2011 in Coding, Python | 0 comments

Spy movies sometimes include a clever fail-save someone set up to activate in the event of their capture and/or death.

My recent idea (while not a new one, but a quick googling didn't turn anything similar up) is just that.

A service that lets you prepare an e-mail and then lies in wait for the moment to send it. Sending the e-mail is delayed as long as the individual keeps regular check-ins with the system.

The project has only the GUI at the moment, I'm planning on writing the backend in Python (GAE), because Heroku's e-mailing limitations look too complex and I want to try something different from PHP.

Link to GitHub

Update:

I started writing the backend code in Python. An unfortunate surprise was how messy type juggling was in Python. Maybe I'm not doing it right, but I expected more elegance.

Anyhow, the "live" version is at http://afterileave.appspot.com/

Making the web experience smoother with loading fades

Posted by David on Jun 15, 2011 in Coding | 0 comments

CSS3 transitions and jQuery animations have greatly affected the web experience. Following up on the idea, here's a quick snippet to make the webpage smoothly fade in/out on page loads.

When you click on a link, the page fades out, leaving only white behind, when the loading of the new page is complete, the page fades in again. A couple of things to note though: the trick will only be useful with really small pages, since loading large pictures leaves the user wondering what the hell happened since (s)he can't see any action. One of the principles of browser design is to show the content as soon as it's available, hence the page 'jumping' one sometimes sees with a slower connection. That said, only use it on cacheable, static and small pages.

First, hide the body of the page with CSS:

body { display: hidden; }

…and add the following JavaScript to hide/show the page. Don't forget to include jQuery first!

$(document).ready(function(){
    $('body').fadeIn('slow');
});

$(document).unload(function(){
   $('body').fadeOut('fast');
});

Update: After using the technique for a while, I noticed several problems with it. Firstly, what happens when the user doesn't have JS enabled? The page stays white. JS crashes due to syntax errors also cause failure with fadeIn. Secondly, if the page is large enough, the user might simply leave. A Loading… spinner would fix that.

Mõttefragmente veebipõhistest kasutajaliidestest.

Posted by David on Oct 2, 2010 in Opinions | 0 comments

Mida tahab veebiteenuse kasutaja rohkem? Praktilist funktsionaalsust, silmailu või lihtsust? Küsimus, millega kasutajaliideste disainerid pidevalt vastamisi seisavad. Ei saa teha Autocadiga võrdse funktsionaalsusega GUI-d, millega saab teha biljon erinevat tegevust, ning hoida see samas silmale ilus (Word 2010) ja rumalatele arusaadav (Web 2.0-laadsed teenused). Kes on teenuse kasutajad? Mida nad vajavad?

Septembri alguses tahtsin end Eesti riigiportaali kaudu Tallinna elanikuks registreerida – mis on ju tore, e-riik ja e-teenused, lihtsa toimingu pärast ei pea linnavalitsusse kohale minema. Vastavat vormi avades avastasin, et uue aadressi sisestamine ei ole üldsegi kerge. Vorm oli jagatud osadeks: ühe välja asemel, kuhu saaks vabas vormis aadressi kirjutada, olid valikvastustega eraldi välja toodud eri üksused (maakond, linn, linnaosa). Kasutatud oli AJAXit, ja klassikalist hierarhiat, st. alustada tuli suurimast üksusest ning seejärel täitis AJAX allpool asuva valikukasti. Kas märkate probleemi?

Sellisel vormil on muidugi oma eelised, aga antud juhul oli see halvasti läbimõeldud. Jõudes valikutega oma majani, ei suutnud ma valida oma korterinumbrit, kuna süsteem arvas, et seda ei eksisteeri. Lehe allservas oli kontaktaadress ning paari päeva pärast tuligi vastus, et administraator oli aadresside andmebaasi minu korterinumbri käsitsi lisanud. Vaene administraator. Kas tal tuleb sama teha veel ~300 000 korda?

Süsteemis võiks kasutada Google Maps stiilis lahendust: kasutaja valigu punkt kaardil, või sisestagu aadress ühte tekstivälja ning süsteem olgu nii tark, et saaks andmed valideeritud ja töödeldud.

Andmete valideerimine on tüütu. Inimesed, kes on programme koostanud ja kasutaja sisestustega tegelenud, peaksid nõustuma. Näide PHP-st. küsides kasutajalt tema nime. Saadud vastust tuleb kontrollida, kusjuures edevam veebileht teeb seda nii kliendi arvutis (Javascript) kui serveris. Kas nimi sisaldab numbreid? Kas on tegemist keelatud sümbolitega (MySQL injection)? Kas ta on min < X < max pikkusega või hoopis tühi? Ahvatlev on kasutaja eest mõtlemine ära teha, asendades tekstikasti valikvastustega. Väga hea, kui tahate teada "Kas olete abielus?" – Jah, Ei. Mitte nii väga, kui küsite arvamust.

IRL korraldas Septembris 2010 oma veebilehel arvamusküsitluse. Puhttehniliselt muidugi hästi koostatud ja ilusa väljanägemisega. Samas – Mari-Liis Jakobson: "Mis puudutab vastusevariantidega küsimusi, siis sealt on näha, et ega erakonda tõenäoliselt kodaniku arvamus niiväga ei huvita, sest probleemide kohta uurimise asemel on nad sinna oma valmislahendused juba üles pannud." (Postimees). Massilise küsitluse puhul on nõnda andmeid palju kergem töödelda, kuid samas saadakse nii ebatäpsemat infot.

Mis ma kogu selle jauramisega öelda tahan? Enne, kui mingit kasutajaliidest teha, tuleks veidike mõelda, kui lolli / targa inimese kasutada see läheb, kui palju neid inimesi on, mida nad praktiliselt vajavad ning mida koostaja sealt tagasi tahab saada.