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.

Openbox i Arch Linux. Litt mer snappy enn Windows 7.

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…

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.

Jeg tror det vil være lurt å gå frem litt saktere. Visjonen din virker rimelig ufokusert. Før du begynner for fullt på programmering og lansering, burde du gjøre en del research. Les om ZUI, affordances, kognetikk osv. Eller enda bedre, les bøker som Jef Raskins (mannen som startet macintosh-prosjektet) The Humane Interface og Donald Normans The Design of Everyday Things. En annen usabilityekspert fra Apple, Bruce Tognazzini, har også skrevet en del interessant på asktog.com.

 

Det virker som du er inne på noe, så stå på, men du burde ha en god idé om hva du skal lage før du lager det.

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.

det jeg tenkte på var i vertfall retningen til debian, siden nvidia og atheros ikke er åpen vil ikke debian inkludere ordentlige drivere. så jeg måtte selv installere nvidia driveren og endre og fiske på xorg

 

men å få en hardware driver opplegg er bare en ide som jeg liker å tenke på

I noen tilfeller kan det virke som om politikken kommer foran fornuften. Det er en del av attituden i open source‐miljøet å unngå proprietære løsninger for enhver pris, men det er brukeren som får svi for det.

 

Så jeg er enig med deg. Jeg syntes det er fornuftig at brukeren får ta avgjørelsen.

Det er nettopp denne politikken som danner hele grunnlaget for friprog, og det er dette som skiller det fra open source som i langt større grad driter i slikt. Det er derfor nyttig å holde de to begrepene adskilt i slike sammenhenger.

 

Dersom man mener at propritær programvare er et onde, er det å skyte seg selv i foten eller enda høyere å tilrettelegge for bruk av slikt. Det er sannsynligvis* mindre produktivt enn å fokusere på å forbedre de ikke-propritære løsningene. Og ikke minst er det en "slippery slope".

 

 

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.

Det er en liten ide jeg har til dette: Flere vinduer på en skjerm, atlså at fullskjerm deles opp i 4 like deler eller spesifiseres etter config fil f.eks 600x400 og resten deles inn 2 fullskjermer. Av f.eks selve skjermens oppløsning er 1078x800

Hurtigsnarvei:

*ctrl+rullehjulet på musa kunna ha forandet opp og ned nummeret?

*bruker standarden på sitt vis i hotkeys

 

Kan sketche vis du er interrisert, det kan bli dugelig siden ingen andre har det(tror jeg ).

Dette likner nok mer på xmonad, ja.

Ta en titt på Clutter for UI-bygging. Benyttes i Moblin 2 og det ser veldig lovende ut

Det kan være aktuelt å basere Brevity på Clutter. Jeg har hatt det på lista over ting som må granskes. Takk for påminnelsen! Er inne og ser på det nå faktisk, og det ser lovende ut.

Hvem/hva er egentlig målgruppen for dette prosjektet? Tolker det som at det passer fint på en tablet eller en ren Internettmaskin (web-caffe), men kanskje ikke noe man bruker på en desktopp?

 

Eller er jeg helt på jordet her?

Målet er ikke å lage et OS strippet for funksjonalitet, men å lage et som gjøre det mer intuitivt å bruke en datamaskin. En krysning mellom en Android, iPhone OS og OS X kan fungere som en midlertidig beskrivelse.

OK.

Jeg ser her i tråden at du snakker om å lage et OS, men ut i fra den kjappe lesingen på webloggen din jeg har gjort, virka det mer som om du først og fremst var ute etter å lage en WM.

Min kommentar du siterer var i tanken på at du lagde en WM.

 

Skal se om jeg får satt av litt tid til å lese gjennom webloggen din litt nøyere...

Godt spørsmål!

Jeg ser forvirringen, og jeg er fortsatt i tvil om hvordan jeg skal presentere prosjektet. Å gå ut med at jeg skal lage et OS høres litt vel ambisiøst ut, når det er kun jeg som står bak. Dessuten kan det være misvisende, når Brevity bygger på Linux‐kjernen og bruker Xorg.

Men nå har det seg slik at jeg vil lage noe enhetlig, altså et OS som kan installeres, startes og brukes. Dette er et langsiktig mål.

Det kortsiktige målet er å lage noe som likner en window manager. Det som skiller det fra andre window managere, er at det ikke bruker Xorg til annet enn å motta input og til å håndtere grafikk. Andre window managere bruker Xorg til å håndtere vinduer, men dette håndterer Brevity.

Planen er å etterhvert gå over til å bruke noe mer lightweight enn Xorg. Wayland er et slik prosjekt, men det er fortsatt tidlig i utviklingen. Andre Linux programmer vil ikke helt uten videre kunne kjøre på toppen av Brevity, noe som er bevisst. Jeg vil ha et UI som har et sammenhengende grensesnitt, i likhet med OS X. Det betyr ikke at jeg skal skrive en nettleser fra scratch, for den baseres på WebKit. WebKit bruker Cairo vektorgrafikk‐biblioteket til å tegne, noe også Brevity gjør.

Applikasjonene for Brevity vil bli skrevet i et API som lages fra scratch. Dette APIet vil være så rikt i funksjonalitet, at man slipper å ha flere konkurrerende biblioteker som gjør nøyaktig de samme tingene. Dette fører til at mindre ressurser brukes, det er enklere for utviklere, siden det kun er et API å forholde seg til.

Håper det ble litt klarere.

så jeg måtte selv installere nvidia driveren og endre og fiske på xorg

En gang jeg fisket på xorg, fikk jeg en ati-driver som var såååååå STOR!

 

 

(beklager, fristelsen ble for stor =)

EDIT:

Brevity virker interessant, men er det ikke andre prosjekter som dette som du kunne forket/utvidet/utviklet ?

Dumt å finne opp hjulet på nytt fra bunnen av...

Jeg har en temmelig sterk visjon for akkurat det jeg har bestemt meg for å jobbe med, og jeg vil unngå å oppfinne det som allerde eksisterer.

Jeg ser mer på det som om at jeg håndplukker det jeg liker, setter det sammen slik jeg vil ha det, og legger til en krydderbit selv.

det jeg tenkte på var i vertfall retningen til debian, siden nvidia og atheros ikke er åpen vil ikke debian inkludere ordentlige drivere. så jeg måtte selv installere nvidia driveren og endre og fiske på xorg

 

men å få en hardware driver opplegg er bare en ide som jeg liker å tenke på

I noen tilfeller kan det virke som om politikken kommer foran fornuften. Det er en del av attituden i open source‐miljøet å unngå proprietære løsninger for enhver pris, men det er brukeren som får svi for det.

Så jeg er enig med deg. Jeg syntes det er fornuftig at brukeren får ta avgjørelsen.

Leste litt paa "What's Brevity"-posten og det ga meg ekstremt lite, hva er filosofien bak det hele?

 

Right‐clicking a window/tab closes it

WTF?

 

Men uansett, er jo alltid morsomt aa see nye eksperimenter, haaper det kommer noe ut av det da

Litt av problemet med bloggen er at jo eldre poster du leser, desto mer vagt er det. I dette tilfellet mente jeg at en skal kunne høyreklikke et program i taskbaren for å lukke det, uten å måtte gå innom en popup‐meny. Dette gjelder ikke lengre, iom. at jeg har planer om et grensesnitt som er helt annerledes.

Men jeg kan si litt om filosofien. Den er å lage et OS som er minst mulig i veien, med et intuitivt grensesnitt. Nå som multi‐touch sakte men sikkert kommer, finnes det kanskje måter å «snakke» til PCen på som gir mer mening enn hva vi har brukt til nå. I seg selv blir ikke brukergrensesnittet eller elementene i UIet noe nytt eller noen revolusjon, men det er sammensetningen som gjelder.

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!

noe jeg savner på andre desktop plattformer er ubuntu's hardware drivers, dette vil gjøre installering av drivere lettere for brukere som ikke er helt på topp for å si det sånn.

 

men dette er jo bare min mening da..

Idéelt sett så bør alt av hardware oppdages og settes opp automatisk. Det går i den retningen nå med både Linux‐kjernen og Xorg. Det er ingen grunn til at en bruker skal gjøre dette selv, med mindre en har helt spesielle behov og samtidig vet hva en driver med.

Forhåpentligvis slipper vi å bruke proprietære drivere fremover, men det er uansett bedre enn ingenting.

Jeg holder på med et prosjekt basert på Linux og open source‐teknologier, og jeg tenkte å legge ut en lenke til bloggen hvis det er noen interesse for det her.

Det er i første omgang snakk om et UI eksperiment, men når ting begynner å falle på plass kan det bli aktuelt å lage utviklingsverktøy, en web browser basert på WebKit, diverse multimedia‐ og kontorapplikasjoner.

Jeg er ikke ute etter noen å samarbeide med på dette stadiget, men jeg setter stor pris på innspill, tanker og idéer som glupe hoder på diskusjon.no måtte ha.

I og med at det er en blogg, og at det er tidlig i utviklingen, vil det ofte være slik at eldre poster ikke lengre gjelder.

Ok, nok prat.

http://brevityos.blogspot.com/

...