Editor Buttons Simplified

WordPress admin interface is great and getting better all the time. One thing though I think has not received any thought in a long time is the selection of buttons on the TinyMCE editor interface.

Update 2015-05-18: The plugin is now available on the official WordPress.org repository with one major modification: there is only one row of buttons and an expand functionality. This works a lot better responsively than two separate rows do.

I have created a simple plugin (on GitHub as well) to be able to easily test the modifications I propose. But I wanted to explain the rationale behind all the changes here.

Here are the WordPress default buttons with the “kitchen sink” open:

That is a lot of buttons.

My initial proposal is this:

Let’s go through the changes now.

Headings are important

If you write a blog post longer than just a couple of paragraphs, you really need headings. The dropdown (called formatselect in TinyMCE) is hidden by default, behind the obscure kitchen sink button. Most users don’t know of its existence, so they end up making a paragraph bold to mark up a heading, which is not good for SEO and certainly is not properly marked up reusable content. Those, that do find the control, are forced to see two rows of mostly useless buttons all the time.

My solution is to put the dropdown as the first item on the default button row.

Heading levels

Here are the current dropdown values:

I do not think one should use h1 inside a post. That should be reserved for the post title only. Also, having all the six heading levels is too much. Three levels are enough for most uses. If you need more, you probably should divide the post into two or more separate articles to make it more readable.

Pre is useful if you paste code, but that is not for most people. Removed.

Here’s the simplified dropdown:

Alignment buttons

Alignment buttons can be used for two things. You can align text and you can align images. Alignment of text does not make much sense. Unless you write poetry maybe. Most users do not.

Alignment of images can be done by clicking an image in question and then clicking the proper alignment button from the popup menu.

Strikethrough and horizontal line

To simplify the default row a bit more, we could move the strikethrough and horizontal line buttons to the second row. Those buttons can be useful, but not most of the time.

Secondary row modifications

I would like to remove the underline button, since one should not write underlined text on the web in general. An underline denotes a link.

One should not use full justified text on the web, unless it can be automatically hyphenated. Until browsers do that, I would remove the button.

Text color choices should not be done by the author. Instead, a style selection tool could be used (that can be activated through the TinyMCE API, if needed for the content and the design of the site).

Indent and outdent buttons do not make sense to me. What is their use case? Remove them, I say.

Here is the end result for the secondary row:

It’s actually so small number of buttons that it almost makes sense to put all the buttons to the same row.

Conclusion

It is easy to revamp the editor toolbar to be move usable, simple and useful.

It will require a way more thorough analysis to make the changes on the product level, but at least for our clients a setup similar to what I have described above makes a lot more sense than the current default.

Carl Haglund ja WordPress

Helsingin sanomat kirjoittaa:

Puolustusministeri Carl Haglundin (r) henkilökohtaiselta verkkosivulta on löytynyt tietojen varastamiseen tarkoitettu haittaohjelma. Virus on naamioitunut yhteydenottoihin tarkoitetulle alasivulle ja ollut siellä tammikuun 23. päivästä alkaen.

Jutussa mainitaan, että ko. haittaohjelma iskee usein WordPress-alustan verkkopalveluihin. Sitä ei sanota, että Haglundin sivut on tehty WordPressillä. Tämä kuitenkin selviää Googlen cachesta ja samoin se, että WordPress-versio on ainakin viimeisen tiedon mukaan viimeisimmässä versiossa.

Erillisessä jutussa Haglund epäilee:

“Tämän päivän tapahtumien valossa näyttää, että se ei ole sattumaa. Tämä vaikuttaa järjestelmälliseltä”, Haglund sanoo.

Virustorjuntayritys F-Securen mukaan viruksen alkuperä viittaa Pietariin.

Haglund uskoo valikoituneensa iskujen kohteeksi, koska vastaa hallituksessa kyberturvallisuusasioista.

Oikein konfiguroiduille ja ylläpidetyille sivuille ei noin vain murtauduta. Todennäköisempää on, että yksi tai useampi seuraavista on totta:

  • Palvelimen käyttöjärjestelmä palvelinohjelmistoineen on jäänyt pahasti ajastaan jälkeen
  • WordPress tai jokin laajennus on jäänyt päivittämättä jossain vaiheessa
  • WordPressin (pää)käyttäjätunnuksen salasana on heikko tai on käytössä jossain muussa salasanat vuotaneessa verkkopalvelussa
  • Ensimmäisen murtautumisen jälkeinen siivoustyö on jäänyt puutteelliseksi

Jos mikään näistä ei ole totta, voidaan vasta sitten epäillä, että kyseessä on jokin muu kuin täysin tai puoliautomatisoitu hyökkäys, joka kohdistuu kerralla tuhansiin verkkopalveluihin. Tällaiset kun muodostavat aivan ylivoimaisen valtaosan kaikista hyökkäyksistä.

Tietysti antaa sekä paremman viestin omasta ammattitaidosta että hivelee enemmän omaa egoa, kun murtautumisen syyksi pannaan henkilön asemaan kohdistuva vihanpito eikä oma heikko tietoturvasta huolehtiminen.

Siivous on annettu teleoperaattorin tehtäväksi, mikä herättää ainakin minussa vähän epäluuloja. Oikeasti työ pitäisi antaa ammattilaisille, jotka tuntevat niin WordPressin kuin verkkosivujenkin tietoturvan. Muuten sivut ovat taas pian täynnä viruksia. Mutta mihinkään isoihin, Haglundin viittaamiin investointeihin ei tarvitse ryhtyä.

Jokaisen verkkosivuja ylläpitävän velvollisuus on huolehtia sivujensa tietoturvasta. Selitykseksi ei kelpaa se, että sivuilla ei ole suurta merkitystä tai että niillä ei ole salaiseksi luokiteltavaa tietoa. Murretut sivut kun aiheuttavat haittaa muillekin kuin verkkosivujen haltijalle.

Räätäli vs. puukottaja

Vierityspalkissa ajauduttiin jokin aika sitten keskustelemaan räätälöinnin semantiikasta. Tämä oli vain sivujuonne varsinaiseen keskusteluun siitä, onko WordPress ylipäätään räätälöitävä alusta. Jälkimmäiseen vastaan tarkemmin erillisessä kirjoituksessa, mutta ensin haluan määritellä mitä räätälöinti mielestäni on.

Räätälöinti on toiminnallisuutta laajentavaa tai muokkaavaa sovelluskehitystä eli ohjelmointia olemassa olevan, räätälöintiä tukevan järjestelmän päälle tiettyyn käyttötarkoitukseen, yleensä yhdelle asiakkaalle tai kapealle asiakassegmentille. Räätälöinti on siis sovelluskehityksen osa-alue. Joskus käytetään ilmaisua “täysin räätälöity”. Sillä tarkoitetaan tietojärjestelmää, joka on rakennettu matalamman tason sovelluskehyksen (framework) päälle. Aivan aidosti täysin räätälöityä koodia tuskin kukaan nykypäivänä enää tuottaa.

Mietitäänpä hetki sanan räätäli alkuperäistä merkitystä. Räätäli sekä tekee vaatteita kankaista (täysin räätälöity) että muokkaa ja korjaa valmiita vaatteita (räätälöity). Kun teknologia mahdollisti sarjatuotannon ja ulkoistaminen halpatyövoiman maihin laski kustannuksia entisestään, räätälin työt vähenivät radikaalisti. Räätäleitä tarvitaan yhä, mutta vain kaikkein rikkaimmilla on enää vara teettää vaatteensa omiin mittoihinsa räätälillä. Nykyisin räätälin tehtävät ovatkin pääasiassa pieniä muutoksia valmisvaatteisiin. Tietojärjestelmän räätälöinti ei ole täsmälleen sama asia, mutta analogia toimii monella tasolla.

Yleensä tietojärjestelmän räätälöinti tarkoittaa ohjelmointia. Sovelluksen asetusten muokkaaminen käyttöliittymän kautta voi olla sekin räätälöintiä, jos näin tavoiteltu kokonaisuus on monimutkainen ja siten vaatii syventyvää ajattelua ratkaisun löytämiseksi – eli kehittämistä (development).

Räätälöintiä voi tehdä hyvin tai huonosti. Huonoa räätälöintiä on esimerkiksi nojata järjestelmän dokumentoimattomiin rajapintoihin, olla hyödyntämättä dokumentoituja rajapintoja kehittämällä kokonaan oma, huonompi ratkaisunsa tai käyttää järjestelmän toiminnallisuutta sen käyttötarkoituksen vastaisesti.

Ehdotan, että tällaisissa tapauksissa ei puhuttaisi räätälöinnistä vaan “puukottamisesta”. Puukotus-termiä käytetään usein ikään kuin kunniamerkkinä, vaikka todellisuudessa puukottaja on erittäin vahva ehdokas Darwin-palkinnon saajaksi. Ihan vähän vain liioitellen: Tällaisen räätälöintitavan ehdottamisestakin pitäisi seurata välitön porttikielto ammattitehtäviin.

Räätälöinti vaatii siis aina syvällistä tietoa järjestelmän olemuksesta. Joitain järjestelmiä voi räätälöidä helpommin kuin toisia. Esimerkiksi WordPress on sekä blogialusta että räätälöitävä sisällönhallintajärjestelmä. Todella hyvä geneerinen sovelluskehitysalusta se ei kuitenkaan ole – ainakaan vielä – mutta joihinkin geneerisiin sovelluskehitystarkoituksiin se voi olla ihan kelvollinen valinta. Hyvä räätäli ei lähde tekemään jotain, joka on vastoin järjestelmän perusfilosofiaa, ellei ole varmaa, että tällaisen räätälöinnin riskit on huomioitu huolella.

Räätälöinti-sanalla on jostain syystä paha kaiku. Räätälöintiä vältellään välillä suorastaan hysteerisesti ja joidenkin järjestelmien (SharePoint) toimittajat jopa suosittelevat, ettei heidän tuotettaan räätälöitäisi lainkaan, mikä kuulostaa aika kummalliselle. Ehkä väärän maineen ovat luoneet puukottajat ja yritykset, jotka osaavat rahastaa myös osaamattomuudellaan?

Päätöksen räätälöinnistä pitää perustua tietoon ja se pitää tehdä järjestelmän ehdoilla. Räätälöinti ja sovelluskehitys yleisemminkin on hallittua riskinottoa. Esimerkiksi dokumentoitujakin rajapintoja käyttävä laajennus saattaa huomaamattaan nojata ei-dokumentoituun sivuvaikutukseen, joka taas voi päivitysten myötä alkaa toimia toisin. Mitä paremmin tällaiset riskit ymmärretään, sitä turvallisemmin räätälöinnin voi tehdä.

Räätälin ammatti on kunniakas käsityöläisammatti. Puukottaja on yhteiskunnan hylkiö, joka passitetaan vankilaan aina tavatessa. Pidetään nämä kaksi erossa toisistaan.

Kaino toive vaatimus­määrittelyjen kirjoittajille

Viime aikoina kaikenlaisia tarjouksien liitteenä olevia vaatimusmäärittelyjä lukeneena on mieleeni hälyttävän usein noussut kysymys: miksi?

Vaatimusmäärittelyt on poikkeuksetta kirjoitettu niin, että haluamme tällaisen ja tällaisen ominaisuuden ja sen tulee toimia täsmälleen näin. Ongelma tässä on se, että vaatimusmäärittelijän kehittämä ratkaisu ei välttämättä ole optimaalisin, koska vaatimusmäärittelijäkin on vain ihminen eikä voi tietää parasta ratkaisua kaikkeen. Koska todellinen tarve jää hämärän peittoon, ei tarjoajalle jää mahdollisuutta esittää parempaa ratkaisua.

Minähän parhaani mukaan esitän kysymyksiä ja pyydän tarkennuksia ja saankin vastauksia, mutta kaikkea en osaa kyseenalaistaa. Eikä se normaalissa tarjouskilpailussa ole edes mahdollista, koska tarjous pitää saada kasaan kohtuullisella vaivalla.

Tuottavampaa olisi, jos vaatimusmäärittelyssä keskityttäisiin ongelmien esittämiseen ja tarvittaessa esitettäisiin joitain reunaehtoja ratkaisulle. Näin tarjoajalle jää mahdollisuus osoittaa todellinen tuottavuutensa.

Muutenkin on tyhmää fiksata ongelmanratkaisutapa siinä vaiheessa kun teknologiaa ei edes ole valittu. Ja tyhmää on myös käyttää yhden tietyn julkaisujärjestelmän tapaa jäsennellä asioita ja olettaa kaikkien toimivan samalla lailla – näin implikoiden että muut tavat tehdä asia eivät ole sallittuja.

Kiitos kun kuuntelitte.