Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Mobile readiness support #424

Open
wants to merge 6 commits into
base: master
Choose a base branch
from
Open

Mobile readiness support #424

wants to merge 6 commits into from

Conversation

cubiclesoft
Copy link

Makes a number of mostly minor adjustments to the SCSS files and a few code changes to the Coffeescript files to cause ContentTools to display reasonably well on all screen sizes from desktop on down to smartphones.

Demo:

https://cubiclesoft.com/Unrelated/ContentTools/sandbox/

The most significant visual and code changes are, unfortunately, in the toolbox. All of the draggable toolbox support has been ripped out and the toolbox is affixed to the right side of the screen with a minimally-invasive right margin override for the content. I spent the past couple of weeks debating what to do here since you clearly sunk a lot of time into the toolbox. As a result, I was quite hesitant to make this particular change but this approach is the only viable solution I could come up with for decent display and interaction on a smartphone - otherwise the screen gets far too crowded and some toolbox controls are inaccessible, especially with a soft keyboard. The only downside that I can think of is a possible breakage in RTL mode since the box now forces a scrollbar to display off screen so that the tools can scroll vertically and independently of the page. Full RTL support is most likely a larger overall issue that usually has lots of little fiddly bits to address.

So far I've only tested in the web browsers at my immediate disposal (Edge, Firefox, and Chrome on desktop, Chrome on Android, and Safari on iOS) and worked out all of the issues that I saw and were readily fixable. Some of the dialog changes might not work well under IE9 but global usage of IE9 and IE10 are hanging around 1% each so I'm kind of hoping that IE9 no longer matters. Even with these changes, the GPU accelerated scrolling on Android can look a little weird and dialogs can still get crowded on mobile devices whenever the soft keyboard appears. However, all of the major components are now at least semi-usable on mobile which is an improvement over not being usable at all. I was only concerned with the high-level ct-app interfaces at this point (i.e. ignition, inspection, dialogs, toolbox), so things like content drag-and-drop still might not work (yet). As such, this PR is more of "a good start" to the mobile-ready conversation rather than something 100% complete.

@anthonyjb
Copy link
Member

Hi @cubiclesoft

First I'm really sorry for the late response and second thank you so much for taking the time to produce this pull request!

As this request breaks the standard UI I can't merge it into the master branch yet but instead I'm going to create a separate mobile_branch and use this as a basis for starting to move forward in developing support for touch based interactions and smaller devices.

I hope you'll continue to contribute to the new branch and that we can (in the not too distance future) make mobile support a feature of CT.

@cubiclesoft
Copy link
Author

Someone once said, "it's always better late than never." :)

I suspected the UI changes, particularly toolbox, would be too big to just accept immediately into mainline. A new branch specifically for dealing with mobile readiness is a great solution.

I agree that touch support for CT is probably the next significant hurdle but I wanted to get your feedback on the first set of changes before proceeding down any particular path. The separate branch will allow a lot of additional freedom to explore various options.

@cubiclesoft
Copy link
Author

cubiclesoft commented Aug 30, 2017

A lot has happened in the last month. I went off to work on semi-related things to the project I'm using CT for but the last two weeks have been entirely focused on the next set of changes for CT: Touch support. I first attempted to get drag-and-drop to work on touch devices but there are multiple issues that I ran into:

  • Long press on touch devices triggered existing built-in browser functionality across multiple browsers (e.g. cut, copy, paste). Anything I tried either didn't work (at all) or interfered with the built-in functionality in unfortunate ways.
  • Horizontal motion is guaranteed to interfere with things such as Android ViewPagers (e.g. embedded ContentTools in a native app). Dragging-and-dropping items to the right would be impossible in some circumstances.
  • Vertical motion is already handled by vertical scrolling. Preventing the default behavior globally for just touch events is the only way to handle this. However, if too much content is on the screen and extends past the area being targeted, stopping the browser from scrolling will cause problems with moving content around.

I ended up reverting my changes for handling touch events and eventually found myself on a different path: Long-press/long-click the tags in the inspection bar. A normal, short click still displays the usual inspector dialog. However, long-pressing draggable elements now displays an anchored dialog with six directional buttons representing the most important actions associated with drag-and-drop. On resizable elements such as images and video, two text fields also appear for controlling width and height, which allows for pixel-precision resizing on all platforms.

The demo has been updated to reflect all of the latest changes:

https://cubiclesoft.com/Unrelated/ContentTools/sandbox/

As a minor bonus, the anchored dialog component still has fixed width but now has dynamic, unbounded height. That could be useful for making other expansions/customizations.

There is one new global configuration option that is disabled by default:

ContentTools.MOVE_SIZE_AUTO_SCROLL

I originally tried to keep the dialog in the same place at all times on the screen by scrolling the view but it's a bit jarring on a smartphone. Disabling the feature does make moving things around a little more cumbersome since the user has to scroll independently but it becomes much more intuitive that the element has moved in the desired direction. I left the code in place just in case someone really prefers the jumping behavior and made it a global configuration option.

The long-press + anchored dialog approach avoids interfering with built-in functionality on touch devices and expands desktop functionality a little bit more. Desktop with a mouse is still the best environment for using CT, but touch devices can now do almost everything desktop can do. I wouldn't want to edit content on a smartphone for too long - maybe just quick two-minute content fixes. However, extended content editing sessions on a tablet with a Bluetooth keyboard is a real possibility.

One other thing: The six new icons are in icons.woff and I updated the selected icons JSON file from icomoon. The JSON file they now export is apparently much smaller than when it was previously exported, hence the "-13,000" changes at the top of this pull request.

@anthonyjb
Copy link
Member

First off - this is fantastic! 🥇

I love the solution to moving/resizing content, it's a very elegant solution for mobile. CT feels entirely usable on a mobile device now which is a huge step. You've made so much progress on the problem.

@cubiclesoft any chance you can request a merge into the mobile_ready branch? And I'll get this merged in straight away then.

Beyond that - from an initial look it doesn't feel like as much work as I expected to merge these changes into the existing CT UI (hopefully no need for a 2.x.x release), e.g supporting floating toolboxes on desktop and fixed on mobile... I'll put together a road map regarding this as part of the mobile_ready branch - but I think given the amazing progress you've made this would be great to get done sooner.

Thank you for contributing back and helping to move the project forward.

@cubiclesoft
Copy link
Author

Glad to contribute!

It would be nice to have a global option to show the fixed toolbox on all devices. For example, ContentTools.FLOATING_TOOLBOX = true by default but always affix it to the side when it is set to false or the screen is too small. Someone might prefer the fixed toolbox to show at all times for reasons only known to them (e.g. writing an Electron app or putting CT into an iframe).

Since the floating toolbox code is going to be merged in (eventually), I'm going to go back to the original master repo and see if I can get drag-and-drop of the floating version of the toolbox to function on all devices while what I know about touch-based drag-and-drop is fresh in my mind. The floating toolbox could still end up appearing on touch-capable laptops (e.g. Chromebooks, Surface), which might result in less than ideal interaction. That's the only issue I can think of at this point.

@DataCourier
Copy link

Just checked out the demo and found two minor issue: upload dialog can't be closed, or used whatsoever, but maybe thats the demo's issue (video dialog didn't have such issue).

Not sure if I need the footer at all, otherwise this is AMAZING! Being able to use such a powerful content editor from my phone is insane.

@cubiclesoft
Copy link
Author

@DataCourier - Hmm. Unlike the video dialog, the default ContentTools image upload dialog requires callbacks to function - that's normal - so why it can't close is possibly related (maybe a Javascript error - been almost a year since I opened this issue). The "footer" is probably the Inspector bar and it is definitely needed for setting classes and moving elements around (especially on mobile). There is a 'mobile-ready' branch on this repo, but if you want something a bit more, IMO, feature-complete and production-ready with some souped up replacement widgets, check out this branch:

https://github.com/cubiclesoft/ContentTools/tree/barebones

See it in action:

https://barebonescms.com/demo/

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants