Are you sure?
Maybe some time later, you’ll be sad about this decision 
Getting back to this and doing some testing… I actually can’t get the edit conflict error to show at all now… Not sure if this is related to your changes @venarius (can’t see anything obvious) or something else…
Here’s how I’m trying to trigger it:
- User A opens composer to edit wiki post (revision 1)
- User B opens composer to edit same wiki post (revision 1)
- User A saves revision
- User B attempts to save revision
I’m seeing the normal saving/saved draft icons in Step 4 both before and after I attempt to save the revision. The modal warning User B that they’re about to overwrite an edit appears correctly.
I tested locally and on Meta and can’t get the edit conflict message to appear. Am I missing something? Can someone else double check?
2 Me gusta
@nbianca can you verify this did not regress?
2 Me gusta
Still not able to trigger the edit conflict, but that seems to be a separate issue.
Preview button is moved here
9 Me gusta
Why is image button below on mobile and not in toolbar like on desktop? I find this a bit confusing…
It’s an important action that isn’t easy to do on mobile without a button, and sometimes the toolbar isn’t visible on mobile (I think the toolbar also used to be hidden more often than it is today) - so it gets called out in a special way.
I could see how it would be confusing if you’re used to the desktop layout, until recently we had the button in both places, which would cover that familiarity… but we didn’t like the redundancy
3 Me gusta
How could you revert the change of location for the preview button?
But why is hiding toolbar still a thing on mobile? I “lost” it once and thought it was a bug at first, that it did not show up anymore. Is really vertical space so big of an issue on mobile, that is worth this complicated UX?
1 me gusta
Yes, Android phones can have tiny screens. There are zillions of different Android devices.
5 Me gusta
Fixed by
5 Me gusta
Parece que la opción 2 (Agregar botón de vista previa junto a la carga de imagen) se implementó. Me gustaría compartir algunas observaciones relacionadas con la experiencia de usuario resultante:
-
Un usuario de mi foro (bastante experto en la web) simplemente no pudo encontrar, por más que lo intentó, dónde había ido la barra de herramientas de formato, hasta el punto de que me contactó pensando que su ausencia era causada por un error. Parece que los planes para mostrar condicionalmente la barra de herramientas en dispositivos Android no se siguieron; ¿sería posible revisar esta idea y quizás implementarla?
-
Además (o como alternativa), sería muy apreciado un ajuste que permitiera desactivar por completo la función de colapso automático de la barra de herramientas y/o definir su estado predeterminado en todos los dispositivos.
-
El botón que controla la visualización y el colapso de la barra de herramientas es un botón de menú hamburguesa, lo cual es un obstáculo adicional para la descubribilidad. También es extraño, dado que ya no hay elementos de menú reales detrás de este botón, solo una acción inmediata y única. ¿Se podría cambiar el icono por algo más adecuado? ¿Quizás una regla recta? ¿O un lápiz?
3 Me gusta