X-post: Notes from WCEU Community Summit.

Mobile Team Community Summit Notes

Call for Testing: WordPress for iOS 8.0

WordPress for iOS version 8.0 beta is available for testing on TestFlight. Not part of the beta program yet? Please sign up for our TestFlight program to request to join as a beta tester.

What to Test:

1. Aztec Native Editor

This build brings the new Aztec editor to public beta. For a detailed list of features and fixes go here.

The more relevant improvements include:

  • Keyboard shortcuts
  • Video interaction now matches image interaction instead of playing videos right away
  • Undo and redo now properly work for attachment insertions
  • Added keyboard support for editing nested lists

Several Bug Fixes & Improvements

There were a lot of other improvements made in this release that aren’t being called out in this post. You can view the entire list here.

Bugs & Feedback

Did you find a bug or come up with a feature request while testing? You can discuss it here, ping one of us in the #mobile WordPress.org Slack room, report it using the TestFlight feedback link, or head straight to the iOS GitHub repository and open a new issue.

Thanks for testing!

#aztec, #beta, #ios, #needs-testing, #wpios

Call for Testing: WordPress for iOS 7.9

WordPress for iOS version 7.9 beta is available for testing on TestFlight. Not part of the beta program yet? Please sign up for our TestFlight program to request to join as a beta tester.

What to Test:

1. Aztec Native Editor

The new editor will be on public beta on version 8.0 of the iOS app, so on this release we are asking you to help us find any outstanding issues. If you want the full details take a look at the release notes.

Go ahead and make a post with it, add some images and videos, style it, etc. Let us know what you think, is there anything else you need to make the switch?

Several Bug Fixes & Improvements

There were a lot of other improvements made in this release that aren’t being called out in this post. You can view the entire list here.

Bugs & Feedback

Did you find a bug or come up with a feature request while testing? You can discuss it here, ping one of us in the #mobile WordPress.org Slack room, report it using the TestFlight feedback link, or head straight to the iOS GitHub repository and open a new issue.

Thanks for testing!

#aztec, #beta, #ios, #needs-testing, #wpios

Call for Testing: WordPress for Android 7.6

WordPress for Android version 7.6-rc-1 has been released in the Google Play Store. You can join the beta from the Google Play Store on your device (under “Become a beta tester”), and comment here or join the Google Plus beta community for more discussion with other testers. (Note: If you see a message that the beta testing program is full, you’ll need to wait for space to open up before you can join the beta. Thanks for your interest!)

What to Test:

New: Unified Media Browser Picker

Your site’s media library (the Media section) has an improved UI (see here), and now it’s been unified as per the work done here. Check it out and let us know if you find any problems!

New on Aztec

This new build uses the Aztec editor latest version (what’s Aztec?) by default, which now has the following improvements:

  • <pre> tag with with white-space formatting support
  • Changing heading type for multiple headings bug fix
  • Disappearing context menu during image upload fix
  • Paragraphs disappearing while deleting fix
  • Toolbar buttons selected state style change
  • Now you can add images from the new WordPress media library
  • Fixed a bug when it wasn’t possible to save an empty draft

More details on the work in Aztec included in this version of WordPress for Android can be found here.

Bugs & Feedback

Did you find a bug or come up with a feature request while testing? Did you try the additional flow testing? You can discuss it here, report it using the “Enter feedback about the app” form in the Google Play Store, or head straight to the Android Github repository and open a new issue.

Thank you for testing!

#android, #beta, #needs-testing, #wpandroid

Call for Testing: WordPress for iOS 7.8

WordPress for iOS version 7.8 beta is available for testing on TestFlight. Not part of the beta program yet? Please sign up for our TestFlight program to request to join as a beta tester.

What to Test

1. Media Library

We’ve added a top-level Media Library section to WordPress for iOS for each site you manage, bringing it in line with WordPress for Android. Previously, you could only access the Media Library for a site when you inserted media in the editor.

Using the Media Library, you can view your media, search, edit metadata, delete items, and upload new items. Please take it for a spin and let us know what you think!

To access a site’s Media Library, simply tap the Media row on its details screen:

Several Bug Fixes & Improvements

There were a lot of other improvements made in this release that aren’t being called out in this post. You can view the entire list here.

Bugs & Feedback

Did you find a bug or come up with a feature request while testing? You can discuss it here, ping one of us in the #mobile WordPress.org Slack room, report it using the TestFlight feedback link, or head straight to the iOS GitHub repository and open a new issue.

Thanks for testing!

#beta, #ios, #needs-testing, #wpios

X-posting Proposal: WordPress Community Conduct Project

Please read + comment on the original post.

Proposal: WordPress Community Conduct Project

Aztec Native Editors Technical Overview

IMG_0024_framed

Introduction

Aztec is a new native rich-text & HTML editor with focus on performance, stability and flexibility. It’s available for both iOS and Android. The primary motivation behind the project was to provide a great editing experience for the mobile WordPress app but it’s being developed as a standalone open-source library, so other developers can use it and build something on top of it.

This post gets more into the technical features and implementations of each of the two flavors of Aztec. The architectures are both complex and this overview should help start the process of understanding how all the pieces work together.

Want to get more involved with testing Aztec? Feel like using Aztec in your own app and contributing back? Read more about Aztec and the release here.

User Features

There are a set of core features that Aztec is aiming to support with its initial release. Both versions of Aztec (iOS & Android) have used very different native implementations/libraries/techniques but the goal is to provide a similar user experience in your app.

Follow is a list of those features – we’ve noted features to be available (TBA) soon if they’re not ready yet.

  • Rich-text & raw HTML editing support with built-in synchronization
  • HTML formatting & color highlighting
  • Paragraph Indentation and alignment. (Android-TBA, iOS-TBA)
  • Ordered and Unordered Lists
  • Nested lists (iOS-TBA)
  • Blockquotes
  • Image support
  • Video support (Android-TBA)
  • Image alignment and text-wrapping (Android-TBA, iOS-TBA)
  • Pre tags. (iOS: renders but doesnt allow adding)
  • Font Styles: bold, italic, strikethrough, underline
  • Font Coloring (Android-TBA)
  • Header styles
  • Line breaks and paragraph breaks
  • Unknown HTML tag editing (iOS: renders but doesn’t allow editing the contents in Visual Mode)
  • Horizontal rule (HR)
  • Code blocks (iOS-TBA)
  • Beautiful HTML source editor (iOS: still not styled, or “beautiful”)
  • Emoji support
  • Spell-check
  • Voice dictation
  • Edit history (undo/redo) (iOS-TBA)
  • RTL language support (Android-TBA, iOS-TBA)

Technical Deep-Dive

iOS

Architecture

  • Aztec.TextView [ GitHub ]
    • Interacts with HTML using the new setHTML() and getHTML() methods.
    • Allows the client App to set the HTML contents, and not have to worry about the parsing.
    • Inherits from UITextView so:
      • It supports RTL text orientation, unicode (and emojis!), dictation.
      • Editing can be switched ON and OFF
      • Can be placed anywhere in your app.
  • Aztec.FormatBar [ GitHub ]
    • Native UI component inheriting from UIView
    • Aesthetically customizable through Aztec.FormatBarItem
    • Logically customizable through Aztec.FormatBarDelegate
  • Aztec.TextViewAttachmentImageProvider [ GitHub ]
    • Allows rendering custom NSTextAttachment subclasses.
    • Used in the example App for custom HTML-comment rendering.
  • Aztec.TextViewMediaDelegate [ GitHub ]
    • Aztec relies on your App’s own networking stack.
    • Does not have network library dependencies of its own.

Technologies

  • Written entirely in Swift 3.
  • Currently targeted at iOS 9+ but will most likely be 10+ when fully shipped.
  • Available through both CocoaPods and Carthage.
  • Currently includes 326 unit tests and 16 UI tests.

Third-Party Dependencies

Aztec iOS was developed to try to keep the dependencies count as low as possible. There are currently only two dependencies:

Challenges We’ve Faced

Synchronization of NSAttributedString and our DOM representation

One of the main goals behind Aztec was to provide a visual HTML editor that would maintain its HTML source intact as much as possible.

The reason is that HTML tends to be very sensible to changes when combined with custom CSS or even with javascript.  We recognized that it would be important to not lose any information between the initial input, and the final output after visually-editing it.

We wanted a file with a few localized edits to look almost the same as the original file.

Part of the problem with not losing information was that NSAttributedString uses a one-dimensional approach to styling, whereas the DOM tree uses a bidimensional approach.  In straight HTML there’s a parent-child relationship between tags (and text-styles) that simply does not exist in NSAttributedString.

Our experimental approach was to basically maintain an NSAttributedString as a sort quick visual cache to show on screen, and to map the edit operations to a parallel DOM structure.

Needless to say, this is a very difficult approach to maintain because there’s a big risk of de-synchronization between the cache and the DOM structure.

We’ve done a lot of work to ensure this is not a problem, and to some degree we’ve been successful, but we’re still suffering a bit from maintainability issues due to the complexity of the approach.

There are some upcoming changes that are aimed specifically at making the code easier to maintain and test.

Newlines

HTML has a lot of implicit newlines we need to deal with.  They exist at the end of block-level elements (block level means they’re elements that exist in their own line).

We call them “visual newlines” because they are only shown to the user in visual mode.

When editing regular content, you can simply edit all of the text nodes involved.  The problem with visual newlines is that editing them means more complicated actions need to take place.

Think about removing the trailing visual newline in a list.  It basically means extending the list to include what’s after it, up to the next paragraph break, and modifying the DOM structure to merge those elements.

We’ve done a lot of progress with handling these visual newlines.  Quite a good amount of effort has been put into making them work, but we think more effort will be needed for specific case we may not have fully considered.

What We’re Really Proud Of

We’re really proud of the work we’ve done to create a generic HTML editing component, that doesn’t feel slow or clunky.  There’s simply no comparison with how it feels when compared to other mobile editors.

The amount of time we’ve put into the architecture has paid off as well.  We still need to improve some sections of the code to make them cleaner and easier to maintain, but for the most part we feel pretty good about the quality of Aztec iOS, and most of the code is properly documented to make it easier to navigate.

The architecture was designed to be easy to write automated tests for.  We’ve been encouraging ourselves to try and write at least one unit test triggering each bug report we get, which has proved to be a key factor in avoiding regressions.

Android

Architecture

Aztec was inspired by a library called Knife, an open-source text editor. Aztec consists of several key components:

  • AztecText [ GitHub ]
    • Native UI view inheriting from EditText
    • The visual editor component
    • Styled text in a form of Spannable
    • Customizable styling with XML attributes
  • SourceViewEditText [ GitHub ]
    • Native UI view inheriting from EditText
    • The HTML editor component
    • Represents the styled text of AztecText in HTML
    • Customizable styling with XML attributes
  • AztecToolbar [ GitHub ]
    • Native UI view inheriting from FrameLayout
    • Used in conjunction with AztecText
    • Applies text styles in visual mode
  • AztecParser [ GitHub ]
    • Non-UI internal component
    • Translator between AztecText and SourceViewEditText
    • Converts styled text (Spannable) to HTML and back
  • ImageGetter [ GitHub ]
    • Interface for loading images implemented by an external module
    • Supplied by the Aztec library client
    • Not dependent on specific networking stack
    • Two sample loader modules available

All of Aztec’s features & capabilities are used and demonstrated in a sample Demo App, which is part of the repository.

Technologies

  • Written primarily in Kotlin
  • Developed using the latest release of Android Studio
  • Library minSdkVersion 14
  • Contains almost 350 unit tests

Third-Party Dependencies

Hurdles

  • Consistent and correct Spannable-to-HTML and HTML-to-Spannable parsing
  • List-editing (adding new items, deleting items, closing a list, etc.)
  • HTML element hierarchy & order preservation
  • Visual newlines around block elements
  • Inconsistencies of certain behavior across different Android API versions

Challenges We’ve Faced

One of the biggest challenges for us was avoiding regression errors by implementing new features & bug fixes. For example, things like list or quote editing involves a fair amount of character-level processing. It is key that the element and newline spans are applied to specific locations around certain characters. This system is sensitive to changes, so a small bug fix in one part of the editor often triggered a cascade and broke things in other parts. To help us overcome this we had to write numerous unit tests for every feature and edge case we could think of. It gave us confidence to see the tests passing after changing something and it would have been nearly impossible to progress without them.

Conclusion

We’ve come a long way since starting on the project in June of 2016.

Aztec has been integrated in the WordPress beta release and with every additional feature & bug fix it is becoming more usable in real world applications. We’ve designed the library to be simple to integrate and we’re continuing to work on the plug-in architecture so that it will be even more extensible and customizable in the future.

Help us test the Aztec native editors by using them in your own project and contributing back. Check out the original announcement post under “How should I report?” for more information on how to get involved.

Call for Testing: WordPress for iOS 7.5

The WordPress for iOS 7.5 beta will be available for testing on TestFlight soon. Not part of the beta program yet? Please sign up for our TestFlight program to request to join as a beta tester.

What to Test

1. Aztec Native Editor

You may have heard about the new editor that’s included (but hidden) in the WordPress app. Aztec has reached beta status and you’re being invited to test it out!

First step: Read about Aztec here. There are instructions on how to enable it.

Second step: Look at the release notes for Aztec to find out what works, doesn’t work. It’s a beta so there’s still work left to be done.

Third step: If you test with updating an existing post, you may wish to use a test site. While we’ve been working super hard to make a solid experience you could potentially lose formatting.

We’re keeping the testing scenarios pretty loose at this point:

  • Compose a new post.
  • Update an existing post.
  • Add images (video support coming).
  • Try formatting things and verify formatting isn’t lost after posting.

Feedback

Something not work right? Did the app crash? Please tell us if something that seems like it should work didn’t.

2. Post Slug editing

On a post you can now edit the post slug (the unique part of a post URL).

Testing steps:

  1. Create a new post.
  2. Tap the ellipsis button and then Options. Tap Slug near the bottom of the list.
  3. Edit the post slug and provide something different than the default. (currently the default is blank – we’re going to supply the standard text before 7.5 ships)
  4. Publish the post and verify the slug is what you provided.
  5. Also try editing the slug on an existing post (using a test post is suggested).

Feedback

Try and break this – leave it blank, put weird stuff in there, etc. Let us know what happens!

Several Bug Fixes & Improvements

There were a bunch of other improvements made in this release that aren’t being called out in this post. You can view the entire list here.

https://github.com/wordpress-mobile/WordPress-iOS/pulls?utf8=%E2%9C%93&q=is%3Apr%20milestone%3A%227.5%20%E2%9D%84%EF%B8%8F%22%20

Bugs & Feedback

Did you find a bug or come up with a feature request while testing? You can discuss it here, ping one of us in the #mobile WordPress.org Slack room, report it using the TestFlight feedback link, or head straight to the iOS GitHub repository and open a new issue.

Thanks for testing!

#aztec, #beta, #ios, #needs-testing, #wpios

Introducing the Aztec Mobile Editors

The hybrid (HTML & JavaScript) approach has worked well enough to bring a rich editing experience to our users. The limitations of the web view has prevented us from giving those users the anything better than a 7 out of 10 experience. The only real solution for us to reach a full 10 out of 10 was to rethink the implementations to get closer to the metal. That means using APIs provided by Apple and Android to make text editing feel like something that was made for the platform.

The mobile team has been hard at work since July 2016 to improve the post editing experience for our users.

Our hope is the Aztec editor is seen as a component that can be used by many iOS and Android apps to provide a rich HTML editing experience. We feel that we could garner a bigger contributor base to the mobile apps simply because this component exists, is free & open, and is super awesome. We’re not biased at all, of course. 🙂

The Aztec Logo

What Does Aztec Give Our Users?

  • Accessibility – Using OS-provided text controls makes every piece of what you can see to be visible to technologies like VoiceOver. We can now properly support our users that require accessibility. Additionally we can now support dictation!
  • Spell Check – Something as simple as spell check is a nightmare to get working properly in the current hybrid editor. No longer a problem with Aztec! This makes the editing experience feel safer for our users.
  • Speed/Performance – Aztec is so much faster and memory efficient since we have control over the small things.
  • Aztec Everywhere – We plan on using Aztec in more than just the editor view. Aztec is actually a text view implementation and lightweight enough to use in many places in the app. Think of being able to send rich text replies to comments and a more robust iOS sharing experience thanks to a fully custom UI.
  • Contribution – We’re packaging Aztec as a component in its own GitHub repository (each platform has its own repo). This makes Aztec something outside users will want to incorporate into their own apps and contribute back to. Quite literally there is nothing like this out there – every editor we could find uses a web view or has very limited support for any HTML.
  • Undo/redo – The Aztec editor supports undo/redo on both platforms. It’s temporarily disabled on iOS until we finalize some bug fixes.
  • Unit Testing – We’re actually able to write unit tests for scenarios that come up and make sure they’re handled consistently. UI testing is also now possible!

What was so Hard?

Editors are hard. I think many of us here working on WordPress can attest to just how difficult dealing with HTML is sometimes. We had a number of technical hurdles to get over. Some of the challenges were:

  • HTML Synchronization/Consistency – Switching between HTML and visual editing mode presents a ton of challenges keeping things in sync. HTML tags that don’t visually alter the rendering need to be retained – dropping that markup would dissatisfy users fairly quickly.
  • Lists & Block Quotes – We’re still having struggles with getting the editing and rendering experience just right with lists and block quotes. They’re deceptively complex and have been one of the places we’re spending the most time on to get right.
  • Amount of Work – There’s just a lot to do with an editor. Edge cases are so numerous that they really aren’t edges. Editors are more like spikey balls on chains.

Okay, I Want to Test it Out!

We wanted to ship Aztec quietly to limit the number of voices providing feedback. The projects aren’t 100% ready for feedback from the full community quite yet but we feel everyone reading this blog can get an early peek. We’d like you to keep some things in mind as Aztec isn’t completely finished on both platforms. We’re not rolling out Aztec to our public beta testers until we’re sure the editing is a beta or better experience.

  1. Aztec is not quite ready for posts where losing formatting would ruin your life. We’re still working out bugs and HTML synchronization between what you see and what ends up on the server is one of the areas we need testing for.
  2. Lists and Blocks aren’t fully finished. Nested lists on iOS aren’t supported yet.
  3. Media support is limited to images. Videos aren’t supported quite yet and images may have some funk with how they’re presented on Android.
  4. External keyboards are supported but not fully feature-enriched. Feel free to use your keyboard with your tablet. Things like the tab key may not be spot-on yet.
  5. You can check out the open issues lists on GitHub to understand what’s left to work on.

Turning on Aztec in the WordPress Apps

You’ll want to become a beta tester for the WordPress app to get access to the newest changes. Join the iOS TestFlight program for Apple devices. Android users can join the beta from the Google Play Store on your device (under “Become a beta tester”).

The next step to using Aztec in the WordPress apps is to unlock it as it’s a hidden feature right now. In the web browser on your device, visit this URL:

wordpress://aztec?available=1&enabled=1

This unhides Aztec in settings and turns it on. You can turn the new editor on & off by following these steps:

iOS: To turn on Aztec in WP iOS 7.2 or newer, navigate to the Me tab, tap App Settings, turn on Visual Editor (which should be on already), then turn on Native Editor.

Android: Turn it on by navigating to the Me tab, tapping the App Settings option, tapping the Set editor type setting, and choosing either Legacy or Visual.

Using Aztec Directly

Each of the Aztec repos also contains a demonstration application to use the Aztec component without it being inside of the WordPress apps. If you want to start hacking away on the component itself, this is the best way to start looking at it.

iOS: https://github.com/wordpress-mobile/WordPress-Aztec-iOS
Android: https://github.com/wordpress-mobile/WordPress-Aztec-Android

What should I report?

  • Discrepancies between what you saw in the editor and what actually got published – If you lost formatting or had other problems we really want to know.
  • Crashes – any time you get the app to crash whilst in the editor, let us know.
  • Content that freaks out the editor – if you found some HTML that the editors just do not like, let us know. We’re looking to bulk up our unit tests with examples that make things get wonky.
  • Anything preventing you from publishing – specifically on iOS we rewrote the code around the entire editing experience. If you discover state issues that don’t let you tap publish (for example), let us know.

How should I report?

  • GitHub – Report issues to the main WP Android or WP iOS repos. If you know for sure the issue lies with the Aztec component you can report it directly to the appropriate Aztec repo.
  • Slack – We’re hanging out in WordPress.org Slack in #mobile.

What’s Next?

Here’s a list of the milestones we have in the project and approximate dates:

  1. Alpha – Turned on for the development team & testers to dog food. We’re here now.
  2. Closed Beta – When the editor is good enough to advertise to beta testers (turn on w/URL) and to get feedback from them. Starting with WPiOS 7.5 beta & WPAndroid 7.3 beta which equates to April 24th.
  3. Open Beta – When the editor is good enough to unhide the option to be able to turn it on/off for everyone (advertise it to App Store users with the caveat of beta). Ideally shortly after closed beta; May 22nd would probably be the earliest.
  4. Release Candidate – When the editor is good enough to turn Aztec on by default but allow it to be turned off. We’re estimating a month or more of beta time; June 19th+.
  5. Full Release – When Aztec replaces all current editors and legacy code is removed. This is mid to late July or later depending a number of variables.

Closer to the open beta we’ll start focusing on improving documentation for contributors on the individual project repositories. You can also look forward to seeing posts here on technical discussions for both platforms.

Special Thanks!

None of this would have been possible without the hard work of: @0nko @diegoreymendez as technical leads,  @rachelmcr heading up our testing efforts, and @heckofanapp @hypest @klymyam @lanteanar @sergioestevao @mbiais @bummytime @folletto @aerych @koke working on the engineering and implementation.

#accessibility, #announcements, #aztec, #editing, #editor, #native