...
Koska tietokantaan oli resursseja(aiempaa osaamista ja tuntemusta) päätettiin sitä käyttää keskeisenä rajapintana tässä vaiheessa suunnittelua. Microjournalista voitaisiin suorittaa kyselyitä Etherpadin tietokantaan ja näin välttyä toimimasta Etherpadin koodissa. SQL-kieli on tässä tilanteessa Microjournalin ja Etherpadin yhteinen kieli, sillä datakyselyn lähetys, sekä vastaanotto onnistuvat ilman alustakohtaisia ratkaisuja.
Toiseksi rajapinnaksi otettiin visuaalinen tila, jossa Etherpad sijoitettaisiin Microjournalin käyttöliittymän "sisälle". Käytännössä tämä tapahtuisi iframe-upotuksella, sekä Etherpadin css-tiedostojen editoinnilla. Näin ei saavutettaisi täysin yhtenäistä käyttöliittymää, mutta ratkaisua puolustaa se että Etherpadilla on brändiarvoa, sekä se, että loppukäyttäjät ovat varsin tottuneita visuaalisesti erilaiseen "editointitilaan". Viimeinen kohta johtuu pitkälti siitä, että siinä ,missä sovelluksia harvoin toteutetaan kokonaan javascriptillä, ovat editorit lähes poikkeuksetta toteutettu sillä.
Iframe-upotus oli mielenkiintoinen valinta, sillä kyseiseen tekniikkaan liittyy sekä teknisiä, että henkisiä yksityiskohtia[viittaus omaan lukuun kappaleeseen iframesta]. Tiivistettynä voidaan todeta, että kyseessä on syyttä parjattu äärimmäisen joustava ja muilla tekniikoilla vaikeasti korvattava visuaalisen käyttöliittymän työkalu.
Suunnittelun aikana tutkittiin Etherpadia, josta paljastui API:n puuttuminen, sekä ainoastaan anekdootti-tasolla oleva käyttäjien tekemä dokumentaatio. Tässä mielenkiintoinen seikka avoimesta lähdekoodista. Vaikka koodi on ilmaista ja vapaasti käytettävää, ei dokumentaatiota välttämättä ole, eikä sitä välttämättä kukaan luovuta ilmaiseksi levitykseen (kuten kirjoitushetkellä näyttäisi olevan Etherpadin tilanne).