The composer needs to be more friendly to iPad Mini

The last couple of months, I’m working with Discourse on my iPad mini.

As you might have noticed, the screen size is pretty limited. While writing, I would guess 55% of the screen is filed with the keyboard, 15% with Safari UI elements, 20% with Discourse UI elemets and the rest is the actual composer module with Preview.

By swiping the page upwards, I could safe 10 % from Safari.

In conclusion: I have 20-30% available of my screen.

  • I’m pretty unhappy about this.
  • We need a new solution for mobile devices (WYSIWYG?)
  • One-time UI elements could be dynamicly hidden.

What are you thinking about some 2-step-assistant like composer? In frist place you are filling title, tags, category… metadata… and as next step you get the most exciting full screen writing experience you can get on iPad / mobile devices.

Feel free to add your thoughts and comment my one :slight_smile:

iPad mini is not a very common device. And since iPad expects standard iPad size (and it is the “same” resolution), mini is always gonna have smaller screen elements.

We use iPad and iPad Pro extensively with Discourse and it works great. If you choose the mini, some “mini”-ness is to be expected…


Strongly suggest you post some screenshots here annotating your problems and suggested solutions.

Keep in mind, in iOS there is 0 way of getting keyboard size from JavaScript (even guessing it is open is not trivial), all we can do is make an educated guess about how many pixels the keyboard takes.

The 2 phase topic creation process was suggested before for mobile and is still on the table.


The iPad Mini might not be a common device but 7" Android tablets are and the experience on there is sub-optimal esp. when in landscape.

I love my iPad mini. It has the perfect dimension and weight for holding it with one hand. The landscape mode is the only mode, I’m able to actually use websites like discourse.

I would like some dynamic UI elements with toolbars and maybe in Word app tab style another view of the raw markup language. The default should be a WYSIWYG view.

Nearly every editor in iOS is more user-frindly as the composer is.

The composer is nice under normal desktop-usecase circumstances but not on mobile devices.

1 Like

So, am I right in suspecting that you’d be happy with a hide/show preview button that you could use? On desktop, that’s in the lower right. From your screenshots, I’m guessing it is under the keyboard. If it were moved to above the preview window, then you could use it.


@sam As we talked recently about this issue, I think we should continuously improve the composer into the Microsoft Word App direction.

  1. The text formatting functions should be always on the top,
  2. tabs would be nice to switch between the source code and a WYSIWYG perspective, maybe if really necessary the current live view without editing capabilities
  3. the text field should be always expended down to the keyboard. Independently from the device orientation and special functions like predictive typing … I would guss Apple (at least) is providing some webkit tool chain to determine the current state…
  4. I wouldn’t provide the split view any longer

The editing experience is directly after the content consuming the most important function of any CMS. Therefore I would wish me more focus on this issue :slight_smile:

Maybe someone else is more experienced into iOS and Webkit development than I am and could give us the right hints.

We have no interest in this direction and will not be pursuing that in any way.

Unfortunately, this couldn’t be the the solution…

Feel free to propose mockups, if you have ideas. But we won’t be building MS Word, sorry.

1 Like

We have lots of interest in this direction but we’re quite well aware that you aren’t for turning or even open to discussing the topic. I don’t think the comment from @markus was about rebuilding Word but the very common request for a simple non-markdown editor. I found an example of a site that appeared to achieve this, i.e. it used markdown under the hood but the default mode was a simple editor whereby typing markdown text wasn’t interpreted as such.

Going back to the original topic about being more mid-screen friendly, I’ve given up using Discourse on my 7" tablet because it’s locked into landscape mode due to being in a Bluetooth case & keyboard and there is so little space for the composition window. It’s not that much better on my HTC One M8 with two lines for the composition window for a new topic. It’s better when replying when there is less on screen such as “Create a new topic” and the title box. The user interface also appears to be locked to a window, i.e. you can’t scroll and pinch zooming is disabled. Although the later seemed like a good idea but most native apps don’t pinch zoom so I’m less worried about that one.

Hiding the preview window on mobile is a kind of double whammy. Markdown is in action but unless you either know markdown (majority of our users don’t and neither should we expect them to) or preview before sending, you can end up with unexpected formatting which you then have to try and edit. Typing #1 at the start of the line is the most common one which changes the heading style. The call to turn markdown off entirely is at best a workaround because no other solutions are forthcoming.

1 Like

It’s unclear if 7" tablets have any future.

The iPad Mini is not really being updated; apparently it doesn’t sell well. And as much as I enjoyed my Nexus 7 (2013) there’s precious little in that form factor on Android at all. Which is weird, since Android is otherwise an explosion of crazy devices…

Possibly but only because large screen phones are effectively edging into the market. PC sales aren’t exactly stellar either but don’t see any plans to drop support for that format. But I do agree that the 7" format is a niche one. I obviously want as much screen real estate as possible but in a portable format. For me 7" is a good compromise. It’ll just fit in my walking jacket pocket or is very easy to carry. Filofax format almost. But I accept that the format has plateaued and focus should be on the Smartphone end where it’s edging up to 6". It’ll be quite bizarre if it does reach 7" :wink: That’s why I’m kind of holding off replacing my sluggish Asus 7" tablet. I’ll most likely buy a 6" phablet.

1 Like

PC sales are enormous, as they encompass all large screen formats, from 13" laptop to 30" desktop. Large phones are pretty close to 7" screen size already, particularly once bezels disappear, which is already happening.

The iPad mini format is perfect for me for nearly all use-cases in my every day life: reading eBooks, websites, … This is the only tablet I can hold with one hand during a long time without any further pain. :wink:

I don’t say, Discourse has to be costumized for fixed device dimension. It’s even more important to have a composer that magnifies reliebile at the corners and don’t waste any space with multiple setting locations (title and categories on top and the tags at the buttom, and the send button on another line), redundant information (editor and preview at the same time), and so on…

I think sometimes this is the best advice for those stuck on 7" display form factors:

1 Like

This is my default perspective.

I don’t need all the meta information at the same time as I’m writing on the text. It could safe a lot of space if these settings are located at another location.

A 2 phased topic creation flow for mobile and tablet is on the table

Tags + topic title + category takes up lots of space


That doesn’t work when it’s in a landscape case with a Bluetooth keyboard, which isn’t exactly common but isn’t uncommon either.

1 Like

I’ve had several members complain about the input window when using an iPad mini

It would seem that Discourse does not consider the iPad mini a ‘mobile’ interface and so delivers the desktop interface. This means that the header menu is not hidden and that a logo designed for the desktop continues to show.

In addition, the input and preview windows jump to the top of the screen, wasting the space and offering no view of the content (this is where an external keyboard is used, so no on-screen keyboard is required)

Here are two screenshots I received:


I’ve only had reports of this on ipad minis. Is this a known issue? Is there a way to force these to use the mobile interface instead?