[bug]Nieuwe editor: ontbrekende knoppen

[Bas170]

Hi,

De nieuwe editor ziet er goed uit, maar toont in een mobiele browser minder knoppen dan er daadwerkelijk zijn:

Mobiel:


Desktop:


Is het mogelijk om in de mobiele weergave dezelfde knoppen te tonen?

Alvast bedankt!

[DaFeliX]

Dank je wel voor je melding.

Het is bewust dat er minder iconen zijn, omdat er op mobiel minder ruimte is en ze dus niet allemaal passen. We hebben daarom een selectie gemaakt die altijd worden getoond, en worden andere knoppen pas getoond als er voldoende ruimte is.

[Bas170]

DaFeliX schreef op woensdag 4 maart 2020 @ 13:19:
Dank je wel voor je melding.

Het is bewust dat er minder iconen zijn, omdat er op mobiel minder ruimte is en ze dus niet allemaal passen. We hebben daarom een selectie gemaakt die altijd worden getoond, en worden andere knoppen pas getoond als er voldoende ruimte is.

Logisch

Is het mogelijk om de video knop wel toe te voegen? Ik kan mij voorstellen dat die redelijk veel gebruikt wordt (door mij iig wel).

[DaFeliX]

Bas170 schreef op woensdag 4 maart 2020 @ 13:22:
[...]

Logisch

Is het mogelijk om de video knop wel toe te voegen? Ik kan mij voorstellen dat die redelijk veel gebruikt wordt (door mij iig wel).

Ja, zeker is dat mogelijk, als er een andere afvalt .

Maar, we weten nog niet zo goed welke knoppen er door wie gebruikt worden, en in welke frequente. We hebben dus nog wat te leren welke knoppen we altijd moeten tonen. Ik denk dat we hier eens goed over moeten nadenken, met gebruikers moeten overleggen en/of a/b-tests voor moeten gaan inzetten. Dit hebben we al op de kaart staan om te doen.

[Bas170]

DaFeliX schreef op woensdag 4 maart 2020 @ 13:28:
[...]


Ja, zeker is dat mogelijk, als er een andere afvalt .

Maar, we weten nog niet zo goed welke knoppen er door wie gebruikt worden, en in welke frequente. We hebben dus nog wat te leren welke knoppen we altijd moeten tonen. Ik denk dat we hier eens goed over moeten nadenken, met gebruikers moeten overleggen en/of a/b-tests voor moeten gaan inzetten. Dit hebben we al op de kaart staan om te doen.

De balk iets minder hoog maken en een tweede rij plaatsen is geen optie?

Ik houd mij aanbevolen voor een eventuele a/b test

Tot die tijd dus handmatig de tag typen.

[Hmmbob]

Ik mis in de desktopeditor ook de Underline knop ([u] .. [/u])

[InFamous]

@DaFeliX Ik liep hier ook tegenaan, kan je de balk niet scrollbaar maken op de mobiele weergave?

[Zeehond]

@Bas170 eventueel kun je zolang onderstaand toevoegen aan je custom css om de video knop tevoorschijn te halen op mobiel.

Cascading Stylesheet:

.rmlToolbarWrapper .rmlToolbar span.video {
    display: inline;
}

[Bas170]

Zeehond schreef op donderdag 12 maart 2020 @ 11:49:
@Bas170 eventueel kun je zolang onderstaand toevoegen aan je custom css om de video knop tevoorschijn te halen op mobiel.

Cascading Stylesheet:

.rmlToolbarWrapper .rmlToolbar span.video {
    display: inline;
}

Thanks, die ga ik even toevoegen!

[Hahn]

DaFeliX schreef op woensdag 4 maart 2020 @ 13:19:
Dank je wel voor je melding.

Het is bewust dat er minder iconen zijn, omdat er op mobiel minder ruimte is en ze dus niet allemaal passen. We hebben daarom een selectie gemaakt die altijd worden getoond, en worden andere knoppen pas getoond als er voldoende ruimte is.

Dit laat volgens mij wel goed zien dat dit waarschijnlijk niet mobile first aangepakt is Nu is mobile first ook niet heilig, maar domweg knoppen helemaal weglaten 'want er is niet genoeg ruimte' lijkt me geen goede oplossing, in wat voor situatie dan ook.

Bijvoorbeeld een pijltje rechts, waarmee je de balk uit kan klappen tot 2x de hoogte, zodat de overige knoppen zichtbaar worden op de 2e rij, lijkt me een stuk beter idee.

[InFamous]

custom css snippet: Volledige RML toolbar mobiel

Maakt de gehele toolbaar beschikbaar op mobiel door middel van zijwaarts scrollen.

@DaFeliX of @crisp mochten jullie geen fix willen, mag ik dan vriendelijk vragen om een extra

HTML:

<div class=“snippet”>

te plaatsen na

HTML:

<div class="rmlToolbar">

Dan kan ik de overflow tenminste alleen op de toolbar zetten in plaats van het gehele reactieveld.

[ Voor 20% gewijzigd door InFamous op 12-03-2020 21:46 ]

[crisp]

@InFamous ik zou

code:

.rmlToolbarWrapper.horizontal

doen zodat je de verticale toolbar bij frontpage reacties intact laat

Ik zal eens kijken of we een extra wrapper div kunnen toevoegen. zou dan denk ik zoiets worden:

HTML:

<div class="rmlToolbarWrapper horizontal">
    <div class="rmlToolbar">
        <div class="buttons">
            ...
        </div>
    <div>
    <textarea rows="15" cols="60" id="messageBox" name="data[content]" tabindex="4"></textarea>
</div>

Kan je daar wat mee?

[InFamous]

crisp schreef op donderdag 12 maart 2020 @ 21:55:
@InFamous ik zou

code:

.rmlToolbarWrapper.horizontal

doen zodat je de verticale toolbar bij frontpage reacties intact laat

Ah crap, die had ik in mijn eigen custom css wel maar door het spelen met mogelijkheden gekopieerd naar mijn snippet. Gelijk even aangepast, bedankt voor de headsup!

Ik zal eens kijken of we een extra wrapper div kunnen toevoegen. zou dan denk ik zoiets worden:

HTML:

<div class="rmlToolbarWrapper horizontal">
    <div class="rmlToolbar">
        <div class="buttons">
            ...
        </div>
    <div>
    <textarea rows="15" cols="60" id="messageBox" name="data[content]" tabindex="4"></textarea>
</div>

Kan je daar wat mee?

Dat zou perfect zijn, dan kan ik de overflow op de toolbar zelf zetten.

[DaFeliX]

Hahn schreef op donderdag 12 maart 2020 @ 21:20:
[...]

Dit laat volgens mij wel goed zien dat dit waarschijnlijk niet mobile first aangepakt is Nu is mobile first ook niet heilig, maar domweg knoppen helemaal weglaten 'want er is niet genoeg ruimte' lijkt me geen goede oplossing, in wat voor situatie dan ook.

Bijvoorbeeld een pijltje rechts, waarmee je de balk uit kan klappen tot 2x de hoogte, zodat de overige knoppen zichtbaar worden op de 2e rij, lijkt me een stuk beter idee.

Wat we nu anders doen is de knoppen op smallere schermen groter tonen, omdat je dan vaak met touchscreens werkt waar het fijn is dat je wat meer ruimte hebt. Hierdoor er iets minder ruimte is en moeten er dus knoppen "sneuvelen" voor mobiel. Ik weet niet of dit mobile-first ontworpen is, maar weet wel dat er dus over nagedacht is.

Je opmerking om meer icoontjes te tonen met pijltjes is een goede en wil ik zeker gaan uitzoeken; en zelfs dan moeten we er nog steeds goed onderzoeken welke iconen we dan standaard willen tonen en welke we willen verbergen.

Zoals @ikloon in Quote-knop in de format bars op mobiel aangaf gaan we de werking van de toolbar nog verder onderzoeken en waar nodig verbeteren. Hij zal dit topic daarin ook meenemen.

[crisp]

InFamous schreef op donderdag 12 maart 2020 @ 22:02:
[...]

Dat zou perfect zijn, dan kan ik de overflow op de toolbar zelf zetten.

Komt a.s. dinsdag mee met de release

[InFamous]

crisp schreef op vrijdag 13 maart 2020 @ 07:55:
[...]

Komt a.s. dinsdag mee met de release

[Bas170]

crisp schreef op vrijdag 13 maart 2020 @ 07:55:
[...]

Komt a.s. dinsdag mee met de release

Goed bezig!

[Hahn]

DaFeliX schreef op vrijdag 13 maart 2020 @ 07:48:
[...]

Wat we nu anders doen is de knoppen op smallere schermen groter tonen, omdat je dan vaak met touchscreens werkt waar het fijn is dat je wat meer ruimte hebt. Hierdoor er iets minder ruimte is en moeten er dus knoppen "sneuvelen" voor mobiel. Ik weet niet of dit mobile-first ontworpen is, maar weet wel dat er dus over nagedacht is.

Ja, er is over nagedacht, aangezien je ook al aangaf dat ervoor gekozen is om de belangrijkste knoppen op mobiel wel te laten zien. Ik zeg ook zeker niet dat er niet over nagedacht is.

Maar dat jij nu (weer) zegt dat er knoppen 'moeten' sneuvelen, is niet waar. Die knoppen moeten niet sneuvelen, dat is een keuze, en wat mij betreft niet de beste. Er zijn zat andere opties, waarbij die knoppen niet hoeven te sneuvelen.

En het is ook helemaal prima om te zeggen dat er nog naar gekeken wordt, en dat dit slechts een eerste versie is, maar je eerste post in dit topic leek vrij definitief te zeggen 'het past niet, dus je doet het er maar mee' (even gechargeerd)

[DaFeliX]

Hahn schreef op vrijdag 13 maart 2020 @ 10:22:
[...]

En het is ook helemaal prima om te zeggen dat er nog naar gekeken wordt, en dat dit slechts een eerste versie is, maar je eerste post in dit topic leek vrij definitief te zeggen 'het past niet, dus je doet het er maar mee' (even gechargeerd)

Dan bij deze mijn excuses, het was niet de bedoeling dat met mijn reactie de kous af was; ik wilde slechtrs aangeven dat er bewust gekozen is dat er op mobiel iets anders word getoond dan op desktop

[nero355]

crisp schreef op vrijdag 13 maart 2020 @ 07:55:
Komt a.s. dinsdag mee met de release

Wordt daarin ook die irritante "Wist je dat!" melding geplet ?!

Of moet ik die ergens in mijn voorkeuren uitschakelen

[Hero of Time]

nero355 schreef op zaterdag 14 maart 2020 @ 14:51:
[...]

Wordt daarin ook die irritante "Wist je dat!" melding geplet ?!

Of moet ik die ergens in mijn voorkeuren uitschakelen

Klik op het kruisje en je krijgt 'm niet meer?

Ik moest iig de browser dev tools in om te weten waar het überhaupt over ging. "Stomme" 'hint' over plaatjes toevoegen dus. Onleesbaar omdat de tekstkleur globaal is, voor mij dus wit, en de achtergrond natuurlijk een nieuw element is, dus ook wit heel licht grijs.

[nero355]

Hero of Time schreef op zaterdag 14 maart 2020 @ 14:56:
Klik op het kruisje en je krijgt 'm niet meer?

Dat werkt wel, maar de volgende keer dat ik inlog met een schone browser is dat kreng er weer!

IMHO moet zoiets gewoon uitschakelbaar zijn of na een weekje of zo door de developers uitgeschakeld worden

Ik moest iig de browser dev tools in om te weten waar het überhaupt over ging. "Stomme" 'hint' over plaatjes toevoegen dus. Onleesbaar omdat de tekstkleur globaal is, voor mij dus wit, en de achtergrond natuurlijk een nieuw element is, dus ook wit heel licht grijs.

Heb je iets van Custom CSS daarvoor of zo ?! Hier is het gewoon leesbaar, maar IMHO weten we het nou wel...

[Hero of Time]

nero355 schreef op zaterdag 14 maart 2020 @ 15:10:
[...]

Heb je iets van Custom CSS daarvoor of zo ?! Hier is het gewoon leesbaar, maar IMHO weten we het nou wel...

Jep, dat heb ik. Eigen dark mode en dan krijg je dat soort onleesbare dingen opeens in beeld schuiven.

[InFamous]

nero355 schreef op zaterdag 14 maart 2020 @ 14:51:
[...]

Wordt daarin ook die irritante "Wist je dat!" melding geplet ?!

Of moet ik die ergens in mijn voorkeuren uitschakelen

custom css snippet: Wist je dat? Alsjeblieft

[nero355]

InFamous schreef op zaterdag 14 maart 2020 @ 15:48:
custom css snippet: Wist je dat? Alsjeblieft

NICE! Thnx!

Helemaal vergeten daar rond te kijken...

[InFamous]

nero355 schreef op zaterdag 14 maart 2020 @ 19:12:
[...]

NICE! Thnx!

Helemaal vergeten daar rond te kijken...

Die bestond nog niet speciaal voor jou gemaakt

[nero355]

InFamous schreef op zaterdag 14 maart 2020 @ 19:20:
Die bestond nog niet speciaal voor jou gemaakt

WAAAAT!!! Serieus ?!

Bedankt man!

[InFamous]

crisp schreef op vrijdag 13 maart 2020 @ 07:55:
[...]

Komt a.s. dinsdag mee met de release

Werkt perfect op deze manier

[crisp]

InFamous schreef op dinsdag 17 maart 2020 @ 20:00:
[...]


Werkt perfect op deze manier

Top!

[Cheesy]

Kan ik even aanhaken in dit topic, gezien het te maken heeft met de extra knoppen.
Op smalle(re) schermen gaat dit mis:


iPhone SE browser Chrome

[crisp]

Cheesy schreef op vrijdag 27 maart 2020 @ 14:47:
Kan ik even aanhaken in dit topic, gezien het te maken heeft met de extra knoppen.
Op smalle(re) schermen gaat dit mis:

[Afbeelding]
iPhone SE browser Chrome

Dat is dan ook wel zo'n beetje het smalste scherm dat er is

Ik zal eens kijken wat we daar aan kunnen doen. Workaround is je telefoon een kwartslag draaien (hoewel je dan qua hoogte weer heel beperkt bent), of het volledige replyscherm gebruiken - die past volgens mij precies op 320px breedte.

[Hahn]

crisp schreef op vrijdag 27 maart 2020 @ 21:04:
[...]

Dat is dan ook wel zo'n beetje het smalste scherm dat er is

Precies de reden waarom je als website daar vanuit moet gaan, en niet voor het gemak 'de meest gebruikte' sizes pakken. En ook al is 320px inderdaad het smalste wat je zult vinden, ik gok dat toch om en nabij 5% van de bezoekers daar gebruik van zullen maken.

[crisp]

Hahn schreef op vrijdag 27 maart 2020 @ 22:40:
[...]

Precies de reden waarom je als website daar vanuit moet gaan, en niet voor het gemak 'de meest gebruikte' sizes pakken. En ook al is 320px inderdaad het smalste wat je zult vinden, ik gok dat toch om en nabij 5% van de bezoekers daar gebruik van zullen maken.

Ik weet niet wat de huidige percentages zijn, maar er komt natuurlijk wel een moment dat we daar niet meer vanuit zullen gaan Ondertussen heb ik lokaal voor deze situatie wat marges verkleint zodat het alsnog netje past. Komt dus mee met de volgende release

[Hahn]

crisp schreef op vrijdag 27 maart 2020 @ 22:47:
[...]

Ik weet niet wat de huidige percentages zijn, maar er komt natuurlijk wel een moment dat we daar niet meer vanuit zullen gaan

Jullie gaan er nu blijkbaar al niet vanuit

Maar zolang een schermgrootte nog minimaal een half of 1 procent aandeel heeft, mag ik hopen dat er wel rekening mee gehouden wordt. Want op een site met dagelijks tienduizenden bezoekers, zijn dat toch nog honderden bezoekers per dag.

[InFamous]

@crisp mag ik vragen welke marges? Dan kan ik dit even fixen in mijn snippet.

[crisp]

InFamous schreef op vrijdag 27 maart 2020 @ 22:53:
@crisp mag ik vragen welke marges? Dan kan ik dit even fixen in mijn snippet.

Ik heb hier niet de exacte selector voorhanden, maar ik heb de marge voor de <span> binnen de toolbar verkleint van 9px 6px naar 9px 4px (specifiek voor de quickreply op de laagste devicegrade).

[InFamous]

Cascading Stylesheet:

.rmlToolbarWrapper .rmlToolbar .buttons span

Maar max-width 499px is toch het laagst?

[crisp]

InFamous schreef op vrijdag 27 maart 2020 @ 23:15:

Cascading Stylesheet:

.rmlToolbarWrapper .rmlToolbar .buttons span

Maar max-width 499px is toch het laagst?

Klopt, maar je kan zelf natuurlijk nog lager gaan in je custom css. Met #quickreply_form kan je hem specifiek maken voor deze situatie.

[InFamous]

Oh nee, heb gewoon de oude margin in mijn snippet gezet. Ik heb de mindere margin niet nodig door de scrolbalk.

[nero355]

Hahn schreef op vrijdag 27 maart 2020 @ 22:50:
Jullie gaan er nu blijkbaar al niet vanuit

En terecht!

Ik heb zo'n iPhone 5 SE onding een tijdje als werktelefoon gehad en die is ongeveer net zo slecht bruikbaar voor een beetje browsen als een oude Nokia N95 of zo met zo'n idioot klein scherm!

De support ervoor is ook vorig jaar afgelopen geloof ik dus tijd om die meuk te upgraden!

[Hahn]

nero355 schreef op zondag 29 maart 2020 @ 22:03:
[...]

En terecht!

Ik heb zo'n iPhone 5 SE onding een tijdje als werktelefoon gehad en die is ongeveer net zo slecht bruikbaar voor een beetje browsen als een oude Nokia N95 of zo met zo'n idioot klein scherm!

De support ervoor is ook vorig jaar afgelopen geloof ik dus tijd om die meuk te upgraden!

Ah ja, jij vindt het niks, dus moet heel dat formaat maar weg. Goed argument.

[nero355]

Hahn schreef op zondag 29 maart 2020 @ 22:04:
Ah ja, jij vindt het niks, dus moet heel dat formaat maar weg. Goed argument.

Nee : Het is al achterhaalde hardware en om daar nu nog aandacht aan te besteden is gewoon zonde van je tijd en geld als Tweakers zijnde

En daarnaast snap ik dus de keuze wel om het niet te doen!

[Hahn]

nero355 schreef op zondag 29 maart 2020 @ 22:07:
[...]

Nee : Het is al achterhaalde hardware en om daar nu nog aandacht aan te besteden is gewoon zonde van je tijd en geld als Tweakers zijnde

En daarnaast snap ik dus de keuze wel om het niet te doen!

Het is geen achterhaalde hardware, want het werkt nog prima, en ondersteunt nog de laatste iOS en browsers. En aangezien het nog een vrij aardig aandeel heeft, vind ik het eigenlijk gewoon dom om daar niet rekening mee te houden.

Plus dat de iPhone SE (niet iPhone 5 SE, zoals jij zei) niet de enige telefoon is met een dusdanig lage resolutie, dus je argumenten gaan sowieso maar voor een deel op.