Jag hade alla tre gränssnittsparadigmen tillgängliga när jag började bygga det här, och jag valde den tråkiga. Det här är essän som förklarar varför, med den faktiska interaktionsmatematiken istället för ett funktionsrutnät — för “tråkigt” var det medvetna resultatet av en riktig avvägningsanalys, inte brist på fantasi.
Varje bokmärkesverktyg på marknaden — varenda ett — binder sig till en av tre former. En rad som sitter ovanför sidan. En sidopanel som lever bredvid den. En dashboard som ersätter ny-flik-sidan och väntar på att du besöker den. Ingen blandar de här; formen är ett grundläggande beslut som avgör nästan allt annat om hur verktyget känns att använda. Så det är värt att faktiskt resonera kring vilken form som passar vilket jobb, istället för att behandla det som ett skalval.
De tre paradigmerna
Rad (alltid synlig, inget sammanhangsbyte). Det här är vad Chromes eget bokmärkesfält är, och vad en andra rad också är. Den sitter ovanför sidan du redan tittar på, permanent, och tar en fast flisa vertikalt utrymme oavsett om du använder den i ett givet ögonblick eller inte.
Sidopanel (ihållande panel, formar om sidan). En vertikal panel som lever bredvid ditt innehåll — tänk en bokmärkeshanterare fastnålad öppen bredvid din surfning. Den är alltid tillgänglig precis som en rad, men den tar horisontellt utrymme istället för vertikalt, vilket betyder att sidan under den blir smalare, inte kortare.
Dashboard (en destination du besöker). En startsida eller ny-flik-övertagande som visar dina sparade länkar, mappar eller sessioner. Till skillnad från de andra två är den inte närvarande medan du surfar — du navigerar till den, använder den, navigerar sedan bort.
De flesta jämförelser i den här kategorin hoppar rakt till en funktionstabell — sökning, taggar, mappar, synk, allt med bockmärken — som om verktygets form var en neutral behållare och funktionerna var hela historien. Det är den inte. Formen avgör när verktyget är i vägen, när det är osynligt, och vad det kostar dig på de nittionio återfinningarna där du inte tänker på verktyget alls, bara försöker komma tillbaka till en sida. Det är delen värd att faktiskt arbeta igenom.
Interaktionskostnadsanalys
Det ärliga sättet att jämföra de här är inte funktionslistor, det är vad var och en kostar dig i tre olika ögonblick: när du sparar något, när du hämtar något, och när du inte använder det alls.
Kostnaden för ett sparande. En rad och en sidopanel är båda redan på skärmen, så att spara är ett drag eller klick utan att navigera någonstans. En dashboard kräver att du antingen öppnar en ny flik (och förlorar din nuvarande, om du inte duplicerar den) eller använder en separat sparmekanism som skriver till dashboardens datalagring bakom kulisserna — ett extra lager mellan åtgärden och var den landar.
Kostnaden för en hämtning. Det är här paradigmerna skiljer sig som mest. En rad: kasta en blick, klicka, klart — ingen navigering. En sidopanel: samma sak, fast den tar redan skärmbredd så den kan redan vara synlig eller ett klick bort. En dashboard: öppna en ny flik, vänta på att den renderas, hitta det du vill ha, öppna det sedan antingen där (och förlora din nuvarande fliks sammanhang) eller kopiera en länk tillbaka. Varje dashboard-hämtning är en liten tur-och-retur.
Kostnaden när du inte använder det. Det är den folk underskattar. En rad kostar en fast remsa vertikalt utrymme, alltid, oavsett om du tittar på den — men den kostnaden är liten och förutsägbar, och den kämpar inte mot sidans egen layout. En sidopanel kostar riktigt horisontellt utrymme kontinuerligt, vilket på allt smalare än en bred stationär skärm betyder att det faktiska innehållet på sidan du läser blir meningsfullt hopklämt, och kan visuellt förstöra responsiva layouter som antog full viewport-bredd. En dashboard kostar ingenting medan du inte använder den — för du är helt enkelt inte där. Det är en verklig fördel för den, och det är det enda ställe dashboards strukturellt vinner.
Varför Chrome självt valde en rad
Det här är ingen olyckshändelse. En rad matchar kornet i hur en webbläsares ramverk redan fungerar — Chromes eget enda bokmärkesfält är en rad, flikraden är en rad, adressfältet är en rad. Att stapla en andra rad ovanpå det mönstret är additivt; det kämpar inte mot webbläsarens befintliga visuella språk på det sätt en sidopanel gör, för en sidopanel måste svara på “vilken sida, hur bred, och vad händer med sidans egen layout när jag öppnar den” — frågor en rad aldrig behöver ställa.
Sidopaneler, gjorda ärligt, måste reservera riktig bredd från sidan. På en full-bredd stationär skärm är det en mindre skatt. På en laptop, särskilt något i närheten av det vanligare 13–14-tums-spannet, eller i ett maximerat webbläsarfönster på en mindre skärm, kan en ihållande sidopanel som äter ett fast antal pixlar tvinga en webbapps egna responsiva brytpunkter in i ett trångt läge sidans författare aldrig testade för — knappar som radbryter konstigt, kolumner som kollapsar tidigt, layouter som antog mer utrymme än de får.
Jag har sett det här hända på nära håll när jag testat sidopanelsformade tillägg mot samma uppsättning webbappar jag använder dagligen: en projekthanteringstavla som kollapsar sin egen sidopanel till bara-ikoner-läge för att den tror viewporten krympte, en chattapp som staplar sin skrivrad på ett sätt den aldrig designades för, en dokumenteditor som växlar till en mobilbredds-verktygsrad. Inget av det är exakt sidopanelstilläggets fel — det tar genuint den bredd det utlovade — men det är en riktig, synlig kostnad radparadigmet helt enkelt inte skapar, för en rad tar höjd sidan vanligtvis har att avvara, inte bredd sidans egen layoutlogik aktivt resonerar kring.
Var varje paradigm ärligt vinner
Inget av det här gör rader universellt korrekta — det gör rader korrekta för ett specifikt jobb, och de andra två korrekta för andra:
- Dashboards vinner för session- och projektöverlämningar. Om det du organiserar är “här är läget för Projekt X per fredag” — en kurerad uppsättning flikar menad att återbesökas som en enhet, eller lämnas över till en kollega — passar en dashboards destinationsbaserade modell. Du hämtar inte en länk femtio gånger om dagen; du öppnar en samling en gång. Toby är det mest kända verktyget byggt helt kring det mönstret — se den ärliga Toby-jämförelsen för var den modellen är värd det och var den inte är det.
- Sidopaneler vinner för referenstungt arbete på en enda skärm. Om du aktivt korsrefererar ett dokument mot ett dussin öppna flikar kontinuerligt kan det vara värt bredden det kostar att ha listan synlig bredvid ditt arbete utan att byta sammanhang — särskilt på en tillräckligt bred skärm där den bredden inte är knapp.
- Rader vinner för högfrekvent hämtning. Om ditt faktiska mönster är att nå efter samma trettio platser dussintals gånger om dagen — en supportkö, ett CRM, en dokumentationssida, ett designverktyg — förstärks radens nästan-noll-hämtningskostnad. Femtio hämtningar om dagen till nästan noll kostnad slår femtio hämtningar om dagen som var och en betalar en sidopanels ihållande breddskatt eller en dashboards tur-och-retur.
| Rad | Sidopanel | Dashboard | |
|---|---|---|---|
| Sparkostnad | Klick/drag, ingen navigering | Klick/drag, ingen navigering | Ny flik eller separat flöde |
| Hämtningskostnad | Nästan noll | Nästan noll | Navigera bort och tillbaka |
| Kostnad vid vila | Liten, fast, vertikal | Kontinuerlig, horisontell | Ingen |
| Passar Chromes eget visuella korn | Ja | Inte naturligt | Inte naturligt |
| Passar bäst | Högfrekvent hämtning | Referenstungt, breda skärmar | Session-/projektöverlämning |
Hur Second Bookmark Bar implementerar raden
Med det resonemanget var raden det medvetna valet, inte det förvalda. Second Bookmark Bar lägger till en andra, kompakt rad ovanför sidan med hjälp av en isolerad iframe-renderare med ett överliggande föräldralager för menyer och popup-fönster — och den reserverar sitt eget utrymme försiktigt på moderna app-skal-layouter, så att saker som en chattapps skicka-knapp eller en dashboards egen nedre verktygsrad inte trycks ut under den. Den där “reserverar utrymme istället för att bara flyta ovanpå”-detaljen spelar större roll än den låter; en naiv overlay skulle kämpa mot exakt den typen av app-skal-layouter en sidopanel redan har svårt med.
Den reserverade utrymmesdetaljen löser dock en renderingskostnad — inte en hämtningskostnad. En statisk rad har en kvarvarande kostnad interaktionsmatematiken ovan inte fångar: att visa fel mapp för sidan du faktiskt är på, vilket förvandlar en enklicks-hämtning till ett mappbyte plus en hämtning. Två mekanismer trycker ner radens kostnad under den “ett klick”-siffran i tabellen. Auto-Switch slår om fältet till mappen du kopplat till den aktuella sidan — en stjärna på platsväxlaren visar när den utlöstes, och du kan alltid överstyra den manuellt — så rätt mapp visas ofta redan innan du tittar upp. Och missfallet, “det är här någonstans”, är en sökpanel i fältet med resultat märkta efter mapp och domän, öppnad direkt på sidan du redan är på, istället för Bokmärkeshanterarens tur-och-retur som är dashboardens kostnad från tabellen ovan — betald precis när du minst vill det.
Den ärliga begränsningen, och jag skulle hellre säga den rakt ut än låta dig upptäcka den: Chrome-tillägg kan inte injicera något gränssnitt — rad, sidopanel, eller annat — på chrome://-sidor eller på själva Chrome Web Store. Det är en Chrome-plattformsbegränsning, inte en lucka specifik för det här tillägget, och den gäller för varje bokmärkesverktyg i den här jämförelsen lika. På de sidorna är du tillbaka till Chromes eget enda fält.
Om din bokmärkesvana ligger närmare “samma trettio platser, hela dagen, varje dag”, vinner raden den faktiska matematiken, inte bara känslan. Om den ligger närmare “kurera ett projekt och lämna över det” gör en dashboard rätt jobb för en annan fråga. Värt att kolla var Raindrop och liknande biblioteksverktyg passar i samma ramverk, och var det andra fältets egna undantagna-sidor- och snabb-dölj-kontroller rundar av radmodellen för ögonblicken du inte vill ha den synlig alls. Och om du vill ha samma klick-och-navigering-ärlighet applicerad på varje inbyggt sätt Chrome redan ger dig att nå ett bokmärke innan du ens överväger en rad, här är den genomgången, räknad.
För samma argument omvandlat till en tabell mot varje specifikt verktyg vid namn — Raindrop, Toby, inbyggda Chrome, och andra — se sida-vid-sida-jämförelsesidorna.