Brevity – en ny desktop plattform under utvikling

[jonnor]

EDIT: til saken. Ville det ikke vært langt bedre å fikset det vi allerede har i stedet for å finne opp ting på nytt? Jeg håper at du er klar over at det du legger frem her er satans sinnsykt mye jobb. Hva er de konkrete fordelene? De bør være meget sterke dersom dette skal lønne seg.

 

EDIT2: sånn litt mer kortsiktig og konstruktivt.

Hva mener du med at Xorg ikke skal "håndtere vinduene"? Hvordan løser du dette rent teknisk? Hvilke fordeler har denne måten å gjøre ting på?

Ditt første spørsmål er besvart tidligere. Når det gjelder ditt andre spørsmål, så vil Brevity baseres på Clutter. Håndtering av vinduer er en relativt liten sak å implementere, og det gjør at jeg samtidig er uavhengig av Xorg. Om jeg skal bruke Wayland på et senere tidspunkt som display server, noe som er planen, så vil jeg uansett ikke kunne bruke Xorg’s vindushåndtering.

Først og fremst er det hyggelig å se at du har valgt å benytte deg av et rammeverk som Clutter. Det gjør at noe av kritikken min ikke er like gyldig lenger, men jeg vil uansett ha sagt dette:

 

I overnevnte post kritisererte jeg implementasjonsprinsippene (i et forsøk på å være konstruktiv), ikke idèene dine. Svært mange gode idèer slår nemlig aldri ann pga av dårlig utførelse/implementasjon. En veldig vanlig felle er at man ikke klarer å begrense seg, og satser på å gjøre mye dypere endringer enn man må gjøre for å få implementert idèen sin. Ikke gjør noe du ikke absolutt MÅ gjøre for å få ting til å virke. Gjør du det vil du ende opp med å flikke rundt på kode som må til for å få systemet ditt til å ha mulighet for å gjøre noen ting i hele tatt istedet for å faktisk få testet ut de virkelige idèene dine. Det som er unikt. Det som er synlig for brukeren. Skal du komme noen vei, må du holde fokuset der.

 

Når du får en idè, som feks:

En idé jeg har er at når brukeren er inne i systemet, så vises en stor «vegg» som i Safari 4. Brukeren klikker hvor som helst på veggen, og et 3x3 rutenett med applikasjonsikoner vises rundt musepekeren. Ikonet i midten er nettleserikon. Brukeren klikker for å starte, skriver inn søkeord i adressefeltet, som i Google Chrome, og taster enter.

Oversatt: start PCen, dobbeltklikk, skriv inn søkeord, tast enter, og du er allerede på Google

ville det første jeg ville gjort være å implementere denne idèen. Hiv sammen noe megakjapt og dirty, for å teste om dette faktisk fungerer slik du forventer. Det bør ta langt mindre enn en dag før du har en funksjonell prototyp. Kanskje det ikke fungerer like bra som du har tenkt?

Hva når musepekeren ikke er direkte over skrivebordet, men en applikasjon istedet? Skal dette "rutenettet" kun vise programmer man kan starte (en "launcher")? Hvordan skal man bestemme hvilke 9 applikasjoner som skal vises? Og dersom brukeren ønsker å starte noe annet enn disse 9, hvordan løses det? Kan det samme prinsippet kanskje representere andre ting også, som "workspaces" eller kjørende applikasjoner (en "task switcher"). Hva med de som kun bruker keyboard, hvordan skal de navigere? Er dette mer effektivt enn tradisjonelle løsninger? Isåfall, hvorfor eller hvorfor ikke?

 

 

Sannsynligvis er det masse greier du har oversett, det må du bare regne med. Du kan ikke tenke på alt i forkant. Derfor er det helt essensielt å teste ting i praksis, så fort som mulig.

Endret 27. juni 2009 av jonnor

[Alexander T]

EDIT: til saken. Ville det ikke vært langt bedre å fikset det vi allerede har i stedet for å finne opp ting på nytt? Jeg håper at du er klar over at det du legger frem her er satans sinnsykt mye jobb. Hva er de konkrete fordelene? De bør være meget sterke dersom dette skal lønne seg.

 

EDIT2: sånn litt mer kortsiktig og konstruktivt.

Hva mener du med at Xorg ikke skal "håndtere vinduene"? Hvordan løser du dette rent teknisk? Hvilke fordeler har denne måten å gjøre ting på?

Ditt første spørsmål er besvart tidligere. Når det gjelder ditt andre spørsmål, så vil Brevity baseres på Clutter. Håndtering av vinduer er en relativt liten sak å implementere, og det gjør at jeg samtidig er uavhengig av Xorg. Om jeg skal bruke Wayland på et senere tidspunkt som display server, noe som er planen, så vil jeg uansett ikke kunne bruke Xorg’s vindushåndtering.

Først og fremst er det hyggelig å se at du har valgt å benytte deg av et rammeverk som Clutter. Det gjør at noe av kritikken min ikke er like gyldig lenger, men jeg vil uansett ha sagt dette:

 

I overnevnte post kritisererte jeg implementasjonsprinsippene (i et forsøk på å være konstruktiv), ikke idèene dine. Svært mange gode idèer slår nemlig aldri ann pga av dårlig utførelse/implementasjon. En veldig vanlig felle er at man ikke klarer å begrense seg, og satser på å gjøre mye dypere endringer enn man må gjøre for å få implementert idèen sin. Ikke gjør noe du ikke absolutt MÅ gjøre for å få ting til å virke. Gjør du det vil du ende opp med å flikke rundt på kode som må til for å få systemet ditt til å ha mulighet for å gjøre noen ting i hele tatt istedet for å faktisk få testet ut de virkelige idèene dine. Det som er unikt. Det som er synlig for brukeren. Skal du komme noen vei, må du holde fokuset der.

 

Når du får en idè, som feks:

En idé jeg har er at når brukeren er inne i systemet, så vises en stor «vegg» som i Safari 4. Brukeren klikker hvor som helst på veggen, og et 3x3 rutenett med applikasjonsikoner vises rundt musepekeren. Ikonet i midten er nettleserikon. Brukeren klikker for å starte, skriver inn søkeord i adressefeltet, som i Google Chrome, og taster enter.

Oversatt: start PCen, dobbeltklikk, skriv inn søkeord, tast enter, og du er allerede på Google

ville det første jeg ville gjort være å implementere denne idèen. Hiv sammen noe megakjapt og dirty, for å teste om dette faktisk fungerer slik du forventer. Det bør ta langt mindre enn en dag før du har en funksjonell prototyp. Kanskje det ikke fungerer like bra som du har tenkt?

Hva når musepekeren ikke er direkte over skrivebordet, men en applikasjon istedet? Skal dette "rutenettet" kun vise programmer man kan starte (en "launcher")? Hvordan skal man bestemme hvilke 9 applikasjoner som skal vises? Og dersom brukeren ønsker å starte noe annet enn disse 9, hvordan løses det? Kan det samme prinsippet kanskje representere andre ting også, som "workspaces" eller kjørende applikasjoner (en "task switcher"). Hva med de som kun bruker keyboard, hvordan skal de navigere? Er dette mer effektivt enn tradisjonelle løsninger? Isåfall, hvorfor eller hvorfor ikke?

 

 

Sannsynligvis er det masse greier du har oversett, det må du bare regne med. Du kan ikke tenke på alt i forkant. Derfor er det helt essensielt å teste ting i praksis, så fort som mulig.

Takk for responsen! Jeg har godt av en påminnelse om å holde fokus. Jeg er allerede i gang med en prototype skrevet for Xorg og Cairo, og neste steg blir å få prototypen skrevet om til Clutter.

 

Du stiller bra spørsmål på slutten av posten. Det var kanskje ment som eksempler på punkter jeg bør tenke igjennom, men jeg kan si litt detaljert om hva jeg har tenkt.

 

«Rutenettet» (sitattegn blir riktig i og med at det ikke blir noe synlig nett) vil fungere som en launcher. Den vil kun komme opp når brukeren klikker på et tomt område på desktopen. Når brukeren flytter musepekeren over en applikasjon, vil et delvis synlig overlay-område komme frem på bunnen av applikasjonen. Her kan brukeren f.eks. søke på en sang, sette på neste eller skru ned volumet. Ofte brukt funksjonalitet for hver enkelt applikasjon.

 

Ved å venstreklikke på en applikasjon åpnes det. Det frister å la brukeren lukke det ved å høyreklikke, men det kan være risky. Å la mamma teste er den eneste måten å være sikker. Klikk-og-dra flytter programmet rundt på desktopen, men jeg ser hvilke utfordringer det kan gi, når jeg allerede har sagt at å klikke åpner programmet (on_mouse_release fungerer, men det er ikke optimalt).

 

Jeg kan ikke garantere at noe av dette vil fungere. For å lage et vellykket UI, må jeg si meg villig til å droppe idéer som folk flest ikke forstår. Hva som fungerer finner jeg ut ved å observere vanlige brukere teste ut produktet til å nå et mål som egentlig ikke har noe med UI å gjøre.

 

Støtte for tastatur betyr alt for meg. Idéellt sett skulle alt unntatt tegning hatt støtte for det. Jeg har brukt OS X i et år, og hadde sannsynligvis brukt det fremdeles om det ikke var for at nesten alt måtte gjøres med musa.

[reichspöbel]

Interessant respons!

 

Visjonen min er klar, men den kan helt sikkert kommuniseres tydeligere. Still så konkrete spørsmål som mulig, så skal jeg prøve å svare.

 

Det finnes ikke noe fasitsvar på hvor mye data som må samles inn før et prosjekt skal implementeres. Det finnes heller ikke noe fasitsvar på hvordan implementeringsprosessen skal foregå. Det er stor forskjell på ulike metodikker. Fossefall er mer i den retning at alt planlegges på forhånd, og deretter skal alt kodes. Agile programming tillater at spesifikasjonen endres underveis.

 

Metodikker er metodikker. Det er tillatt å følge intuisjonen og å eksperimentere, iallefall innen et open source‐prosjekt. Jeg kan bli sett på som usikker fordi planen endres underveis på bloggen, men jeg lar planen endre seg når jeg vet det vil føre til et bedre produkt—selv om det er en 180 graders sving fra utgangspunktet!

 

Takk for lesetips forresten.

Jeg vil påstå at hvis du ikke klarer å kommunisere visjonen din slik at andre forstår den, så har du den heller ikke klart for deg selv. At du også sier at man burde se bort fra eldre poster fordi mye har endret seg, styrker den påstanden. Å snakke om prosjektmetodikk for et enmannsprosjekt, hvor du innehar alle roller, kunde inkludert, og som ikke har økonomiske eller tidsmessige rammer, er litt overkill. Men et prosjekt må, uansett metodikk, ha en klart definert visjon og målsetninger, og en del tekniske beslutninger må også tas i forkant (man kan f.eks. ikke hoppe fra Java til Python midt i et prosjekt, selv om man bruker en smidig metodikk).

 

Jeg forstår at du legger mye vekt på brukertesting, og at du derfor legger opp til at mye vil endre seg underveis, men mye av dette har allerede blitt gjort, og det er derfor unødvendig for deg å reprodusere disse empiriske datene og finne opp hjulet på nytt. Derfor foreslår jeg at du starter med å gjøre litt research. Det er også lurt, og standard praksis innen MMI-arbeid, å jobbe med prototyping, på papir, i GIMP, i HTML eller lignende, før man begynner å implementere grensesnittet. Det er heller ikke noe i veien med å gjøre prototyping i kode, men ikke begynn med å programmere hovedprosjektet før du vet hva du skal bruke (du har jo allerede hoppet fra cairo til clutter), hvordan arkitekturen skal være, og i stor grad hvordan hovedelementene i grensesnittet vil fungere.

 

Det er ditt prosjekt, og du gjør selvfølgelig som du vil, men dette er gode råd som kommer fra min egen og andres erfaring.

[Alexander T]

Interessant respons!

 

Visjonen min er klar, men den kan helt sikkert kommuniseres tydeligere. Still så konkrete spørsmål som mulig, så skal jeg prøve å svare.

 

Det finnes ikke noe fasitsvar på hvor mye data som må samles inn før et prosjekt skal implementeres. Det finnes heller ikke noe fasitsvar på hvordan implementeringsprosessen skal foregå. Det er stor forskjell på ulike metodikker. Fossefall er mer i den retning at alt planlegges på forhånd, og deretter skal alt kodes. Agile programming tillater at spesifikasjonen endres underveis.

 

Metodikker er metodikker. Det er tillatt å følge intuisjonen og å eksperimentere, iallefall innen et open source‐prosjekt. Jeg kan bli sett på som usikker fordi planen endres underveis på bloggen, men jeg lar planen endre seg når jeg vet det vil føre til et bedre produkt—selv om det er en 180 graders sving fra utgangspunktet!

 

Takk for lesetips forresten.

Jeg vil påstå at hvis du ikke klarer å kommunisere visjonen din slik at andre forstår den, så har du den heller ikke klart for deg selv. At du også sier at man burde se bort fra eldre poster fordi mye har endret seg, styrker den påstanden. Å snakke om prosjektmetodikk for et enmannsprosjekt, hvor du innehar alle roller, kunde inkludert, og som ikke har økonomiske eller tidsmessige rammer, er litt overkill. Men et prosjekt må, uansett metodikk, ha en klart definert visjon og målsetninger, og en del tekniske beslutninger må også tas i forkant (man kan f.eks. ikke hoppe fra Java til Python midt i et prosjekt, selv om man bruker en smidig metodikk).

 

Jeg forstår at du legger mye vekt på brukertesting, og at du derfor legger opp til at mye vil endre seg underveis, men mye av dette har allerede blitt gjort, og det er derfor unødvendig for deg å reprodusere disse empiriske datene og finne opp hjulet på nytt. Derfor foreslår jeg at du starter med å gjøre litt research. Det er også lurt, og standard praksis innen MMI-arbeid, å jobbe med prototyping, på papir, i GIMP, i HTML eller lignende, før man begynner å implementere grensesnittet. Det er heller ikke noe i veien med å gjøre prototyping i kode, men ikke begynn med å programmere hovedprosjektet før du vet hva du skal bruke (du har jo allerede hoppet fra cairo til clutter), hvordan arkitekturen skal være, og i stor grad hvordan hovedelementene i grensesnittet vil fungere.

 

Det er ditt prosjekt, og du gjør selvfølgelig som du vil, men dette er gode råd som kommer fra min egen og andres erfaring.

Produktet må skisseres, men det gjelder også organiseringen. Det som skiller dette prosjektet fra en del andre prosjekter, er at store deler av planleggingen foregår i full offentlighet.

 

Back to work…

[Alexander T]

Jeg må først og fremst takke alle som har bidratt med tilbakemeldinger i denne tråden. Det har tilført prosjektet mye positivt!

 

I kveld har jeg jobbet med et tidlig utkast som kan gi et lite intrykk av hvordan jeg tenker at OSet skal se ut fra nettleseren. Det har visse likhetstrekk med OS X, men som dere kan se, så er jeg ikke noen stor fan av 1–2‐pixel kanter, mange lag med menyer og denslags. Når jeg skrur på dataen og vil surfe, så vil jeg ha god plass til nettopp det.

 

 

Edit: Av en eller annen grunn så vises bildet med inverted farger hos meg, men det blir riktig i stor størrelse. Ser jeg har en firkant som strekker seg litt langt nederst. Pytt pytt.

Endret 6. juli 2009 av Alexander T

[reichspöbel]

Ser interessant ut, men jeg savner en forklaring på de ulike elementene.

 

Stå på, og vis oss gjerne mer etterhvert som prosjektet går fremover