Webbaserede værktøjer

Jeg har lidt et had/kærlighedsforhold til webbaserede værktøjer. Her tænker jeg på alt fra "test om et domæne er registreret" til Bugzilla og gmail.

Det er rigtig rart altid at kunne tilgå sit værktøj via nettet uanset om jeg sidder ved min bærbare eller ved min maskine på arbejde. Som udvikler er det rart at jeg kan lave den slags ting og sætte dem i drift uden at bekymre mig om hvad brugerne har på deres maskiner. De skal bare have en rimlig basal browser.

Som bruger har jeg det noget svære med den slags værktøjer. De er sjældent fleksible nok hvis jeg har behov for at gøre det samme 100 gange. Desuden har jeg ikke rigtigt fundet en browser der implementerer en brugergræseflade til webforms, som jeg kan holde ud at arbejde med i lang tid ad gangen. Største problem er textarea-felter, der er ikke en rigtig editor og folks forsøg på forskellige rich text ting gør det bare endnu værre.

Problemet med textarea-felter løser jeg med en extension til Firefox der lader mig åbne teksten i vim (It's all text). Ved rich text ting skal jeg ofte lige finde knappen der slå den fra og giver mig et råt textarea.

Men hvordan undgår jeg at skulle lave de samme 100 operationer ved at klikken rundt i en browser i hånden' Her må jeg vel tage udviklerkasketten på og spørge "Hvad kan jeg som udvikler gøre for at værktøjet også bliver brugervenligt for komandolinjefolk'"

Først og fremmest bør man selvfølgelig adskille funktionalitet og brugergrænseflade. I bedste fald kan jeg så lave nogle scripts på serveren der kalder funktionalitets-modulerne, som jeg så kan sætte sammen i shell-scripts. Skal der være fjernadgang kan jeg pakke funktionaliteten ind i en passende RPC-model.

En anden model jeg overvejde var at adskille data og layout i det som serveren sender til browseren. For eksempel ved XML og et passende XSLT. Det øger så kravene til de normale brugeres browsere. Denne løsning kræver nok noget mere adhoc-arbejde end RPC-modellen.

Gør I andre jer lignende tanker og hvordan løser I dem?

Kommentarer (8)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Bjarke Sørensen

Jeg har set forsøg på det, men aldrig noget virkelig godt, men man kunne "sagtens" implementere en slags shell i en web-app, men man vil være afhængig af mere en bare flad HTML ellers er det, som du også ærger dig over, ulideligt at bruge.

Spørger du som udvikler af web-apps eller overvejer du et lag ovenpå web der gør forskellige apps nemmere at arbejde med?

  • 0
  • 0
Finn Sørensen

Der er faktisk en del muligheder i Firefox;
Autofill Forms er f.eks. regelbaseret formularudfyldelse med rimeligt mange muligheder:
https://addons.mozilla.org/da/firefox/addon/4775

Der er mange andre af samme type (Scribe, Text Complete, Formfiller, AutoFormer, iMacros m.fl.).

Det samme gælder såmænd wysiwyg-muligheder, et eks. er BBComposer:
https://addons.mozilla.org/da/firefox/addon/3795

  • 0
  • 0
Peter Makholm

TestGen4Web ser ud til primært at være rettet mod at lave regressionstest af webting. Jeg kender godt værktøjer der kan optage og afspille en browser session, problemet er ofte hvis man har brug for meget mere dynamisk logik end 'udfyld formularen fra denne csv-fil'. Så begynder det at blive svære.

Med hensyn til onlien shell, så er pointen ikke at lave atter en fuldstændig brugergrænseflade der dog ligner mit vante miljø, men at give adgangen i selve mit vante miljø. Det vil sige enten gennem kommandolinjen eller gennem mit foretrukne programmeringssprog. Altså hvad kan udvikleren af et webbaseret værktøj gøre for at unixteknikeren lettere kan mis- eller genbruge værktøjet?

  • 0
  • 0
Jacob Sparre Andersen

Hvis jeg har forstået spørgsmålet ret, så handler det om hvordan vi kan konstruere værktøjer så både »tilfældige« brugere og teknikere opfatter dem som brugervenlige.

Min umiddelbare reaktion er at der selvfølgelig skal to forskellige protokoller til: En webgrænseflade til de »tilfældige« brugere, og en specifik og enkel IP-baseret protokol til teknikerne.

Det giver ved første øjekast et mere kompliceret system. Men hvis vi lader det egentlige værktøj snakke teknikerprotokollen, og lader webgrænsefladen være en oversætter mellem den værktøjsspecifikke protokol og HTTP/HTML/ECMA-script/m.m., så får vi måske i virkeligheden et mere robust system oven i købet.

IMAP-servere og SquirrelMail er så vidt jeg har forstået det et eksempel på den konstruktion jeg forsøger at beskrive ovenfor. DSB S-togs »Byens Puls« er et andet eksempel - her er der dog lukket for generel adgang til den bagvedliggende server.

Jacob

People in cars cause accidents. Accidents in cars cause people.

  • 0
  • 0
Peter Makholm

REST-ideen med JSON, curl og vim er interessant. Jeg er ikke webudvikler, så JSON er ikke rigtig noget der er på min radar. Det vil også virke når jeg skal "gøre det samme 100 gange", ved at bruge et passende JSON-modul til mit foretrukne programmeringssprog.

Jeg havde ikke helt overvejet at webmail og IMAP egentligt er lidt det forhold jeg efterspørger. Men efter min mening er IMAP ikke en simpel protokol og da slet ikke noget jeg vil finde til efterlevelse som adhoc-protokol. For eksempel vil jeg nok lade protokollen være tilstandsløs.

  • 0
  • 0
Log ind eller Opret konto for at kommentere