The block editor is coming to the mobile apps

I’m proud to announce that we’ll be shipping the first public version of the blockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. editor in the apps with their 11.9 release. This release will be available for betaBeta A pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process. testers today (learn more about testing the apps), and the general public in March 11th.

What to expect

For this first version, our main focus was to build a pleasant writing experience with support for the most basic types of content.

Our data showed that 90%+ of the posts created on the mobile apps consisted of basic text and images, so we decided to focus on supporting the Paragraph, Image, and Heading blocks on this version.

Within those limits, we wanted this to be functional and usable as a replacement editor from the start, so we did a lot of work on making sure the little things that you would expect to work on an editor were there: pressing enter would create a new paragraph block, support for undoing and redoing edits, basic formatting,…

Known issues

  • On iOSiOS The operating system used on iPhones and iPads., using typing suggestions sometimes removes spaces between words.
  • On iOS, dictation doesn’t work at the moment.
  • On Android, when you insert a Heading block it initially shows no formatting.

How to test the block editor in the apps

Once you have version 11.9 of the apps, the block editor will be available, but not always used by default. When you edit an existing post, it will detect if it has block content and open it in the block editor, otherwise it will open in the classic editor. If you prefer to edit a post with blocks in the classic editor you can still do so by going to the editor menu (•••) and choosing “Switch to Classic Editor”.

When you create a new post, it will use the classic editor by default. To change that, you can go to Me > App Settings and enable the Use Block Editor option, and every new post will be created in the block editor.

What’s next

After the release, we will start working on some UXUX UX is an acronym for User Experience - the way the user uses the UI. Think ‘what they are doing’ and less about how they do it. improvements and visual refinements that didn’t make it in time, and any major bugs that comes up. Shortly after that we’ll also spend time adding support for the most common blocks and use cases.

Get involved

You can follow along on the Gutenberg and gutenberg-mobile GithubGitHub GitHub is a website that offers online implementation of git repositories that can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged be the repository owner. https://github.com/ repos, and if you have any questions or want to get involved, you can discuss here or find us in the #core-editor and #mobile rooms in WordPress.org Slack.

Gutenberg in the apps: what to expect

The team in charge of bringing GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ to mobile is hard at work, and we’ve seen some really nice progress in the past month: Gutenberg Mobile working inside the apps and the first post published with it, the writing flow has improved so it’s starting to feel more like an editor and less like a collection of isolated blocks, we have a working toolbar in place, you can now select images from your media library,…

We’ve also updated the apps to warn users if they try to edit a Gutenberg post with our existing editor:

Besides the current progress, we have planned the next two milestones: an alpha next month, and an early betaBeta A pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process. in February.

Alpha, December 2018

We will have an alpha release at the end of the year that will showcase the editing flow with some selected basic blocks. We will have a basic integration with the apps, enough to be able to experience Gutenberg (via secret opt-in or special builds), but won’t be showing this to users. Being able to use early versions of Gutenberg directly in the apps will make it easier to gather feedback and do user testing.

Our first release is not meant for end users, as it will only support very basic content: heading, paragraph, and images from the media library. We’re moving from the stage of making blocks work on native to actually building an editor, so there’s a lot of focus on the writing experience and getting this in the apps.

Progress is looking pretty good so far, and we’re still confident we can ship this next month. You can follow along in the Github milestone.

Beta, February 2019

We’ll ship our first beta in February 2019. We want it to be pleasantly usable, but we need to balance that with shipping early to provide a useful solution to those needing to edit existing Gutenberg content. We will support only the most common types of content, but writing a post using those is hopefully as pleasant as doing it with Aztec, things work as expected and writing a post is not frustrating. This is what we scoped as 1.0, but we will adjust the scope depending on what we hear from users after the public release of Gutenberg.

Back in September, we defined what we thought would be a good 1.0, and we were looking at shipping that in Q1. But as Gutenberg rolls out to users on the web, we might see a good amount of users hitting problems trying to edit Gutenberg posts on Aztec. We have done (and keep doing) a lot of work to try to make that as good as possible, but there are limits to how compatible we can make the existing editor. We want to reduce the gap between gutenberg launching and having a version in the apps, so we’re adjusting scope a bit to ship in February. As we hear more from our users, we might still reconsider scope to shift that date.

You can follow along in the Github milestone.

Beyond the beta

Once we have the alpha in place, we’ll be able to put this in the hands of testers and do some user testing, which will help us evaluate our priorities after the first beta.

Also, we’ll start planning soon what our roadmap should be to support blocks from plugins, and start the discussions to make that happen.

You can follow along on the Gutenberg and gutenberg-mobile GithubGitHub GitHub is a website that offers online implementation of git repositories that can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged be the repository owner. https://github.com/ repos, and if you have any questions or want to get involved, you can discuss here or find us in the #coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress.-editorand #mobile rooms in WordPress.org Slack.

Next Steps for Gutenberg Mobile

We want to share a quick update of what we have been up to with GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/, and what’s next.

Since the last update, we have been learning more about Gutenberg and ReactReact React is a JavaScript library that makes it easy to reason about, construct, and maintain stateless and stateful user interfaces. https://reactjs.org/. Native and spent some time improving the interoperability of our current editors with Gutenberg. We’ve also planned an initial roadmap to a first prototype about 3 months from now.

This first version is not meant to be very useful for users, but we’ll have a good foundation to build upon that includes the main Gutenberg components, and we’re hoping it will help us uncover any potential roadblocks early. We’ve organized the work into four milestones:

M1: RichText component, Parser, Unsupported blockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience.

The app can show the blocks that are supported, showing the unsupported block for the rest. We support the paragraph, code, and more blocks, and you can edit the text but not change the style. You  can rearrange blocks using up/down buttons.

We’ll look into loading and saving the editor contents. We expect this to be easy and ship it in this milestone, we want to learn about it early even if if it’s not, but it might be postponed to a future milestone.

M2: Toolbar, Inserter

This introduces a basic toolbar and with it comes styling support. You can now add basic styling to a paragraph and we support the heading block.  You can add any of the supported blocks to the editor.

M3: Inspector

This milestone introduces the a inspector view where you can modify attributes for existing blocks. We’ll also do some initial research on what needs to happen so a new block is created when you press enter, and an empty block deleted when you press backspace.

M4: Media

This milestone will add initial support for media. The editor will be able to display existing image blocks and modify their properties. You will also be able to replace the existing image with a different one, but it won’t be uploaded anywhere.

You can follow along on the Gutenberg and gutenberg-mobile GithubGitHub GitHub is a website that offers online implementation of git repositories that can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged be the repository owner. https://github.com/ repos, and if you have any questions or want to get involved, you can discuss here or find us in the #core-editor and #mobile rooms in WordPress.org Slack.

Gutenberg on Mobile

The mobile team has been looking at GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ lately, and while it’s too soon to have a detailed plan, we thought we’d share an update on where we stand so far.

We want to support Gutenberg on the mobile apps. And for Gutenberg to be successful in the apps, we believe we must strive to support the full experience, and not a limited feature set. We believe Gutenberg and the concept of blocks has the potential to reshape the way people customize and extend WordPress, and the apps should be a coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. part of that experience. Getting this right opens up a level of extensibility on mobile that we have never been able to support with the existing pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party infrastructure.

To make this a reality, we have been experimenting with ReactReact React is a JavaScript library that makes it easy to reason about, construct, and maintain stateless and stateful user interfaces. https://reactjs.org/. Native the past weeks, and we keep doing research on what we’re going to need to build this. Our plan is to adapt Gutenberg to make its primitives run both on web and native platforms, then have some platform-specific components, like Aztec for RichText, or our own Media pickers.

We are still in the process of discovering what changes will be necessary, but so far we know that:

  • Blocks will have to rely on a given set of known primitives that are implemented in all platforms if they are to be mobile compatible, instead of using plain HTMLHTML HTML is an acronym for Hyper Text Markup Language. It is a markup language that is used in the development of web pages and websites..
  • We need to find a solution for styling. CSSCSS CSS is an acronym for cascading style sheets. This is what controls the design or look and feel of a site. is a given on the web, but not on mobile.
  • Blocks should not access the DOM directly, since React Native doesn’t use the DOM. There might be other JavaScriptJavaScript JavaScript or JS is an object-oriented computer programming language commonly used to create interactive effects within web browsers. WordPress makes extensive use of JS for a better user experience. While PHP is executed on the server, JS executes within a user’s browser. https://www.javascript.com/. limitations.

Beyond technical limitations, Gutenberg and blockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. developers will have to consider that their UIUI UI is an acronym for User Interface - the layout of the page the user interacts with. Think ‘how are they doing that’ and less about what they are doing. will run on different platforms and screen sizes, and use a design that works across all of them. We’ll hopefully provide a tool set to help block developers make their blocks mobile compatible.

There are still a lot of unknowns, but we are very excited about this project, and its potential to bring the apps closer to core and allow for much more customization than is possible today.

You can expect to see some discussion happening on the Gutenberg and gutenberg-mobile GithubGitHub GitHub is a website that offers online implementation of git repositories that can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged be the repository owner. https://github.com/ repos, and we’ll make another post here once we have a clearer roadmap. If you have any questions or want to get involved, you can discuss here or find us in the #core-editor and #mobile rooms in WordPress.org Slack.

I just went through the latest reviews 1…

I just went through the latest reviews (1 to 3 stars) and forum posts and, while the sample is small, here are the top issues detected:

  1. Wrong Credentials/Can’t login
  2. Self hosted issues
  3. HTTPHTTP HTTP is an acronym for Hyper Text Transfer Protocol. HTTP is the underlying protocol used by the World Wide Web and this protocol defines how messages are formatted and transmitted, and what actions Web servers and browsers should take in response to various commands. Auth
  4. External keyboard issues
  5. Visual editor
  6. 2 step auth (I think many people don’t know about app specific passwords, some credential issues might actually be 2-step related)
  7. Old posts in app after draft update
  8. Duplicate reader items

Some of those (specially the 2 first) are usually quite vague and why having a direct contact will be great.

I haven’t included stuff that it’s already fixed on 3.8.3. I’ve included HTTP Auth even though it’s fixed on develop to highlight that it’s something we need to test better.

So, highest priority items for 3.8.4:

  • #212 – In-app feedback. @astralbodies let me know if you could use some help in there. I liked @twitkin suggestion on the initial mockups of just adding a ‘Need help?’ link at the bottom of the login screen. Can @twitkin or @hugobaeta review the UIUI UI is an acronym for User Interface - the layout of the page the user interacts with. Think ‘how are they doing that’ and less about what they are doing. flow from can’t add site to contact us?
  • #268 – Clean up logging. Our logs are a mess and not very helpful most of the times. Since the feedback option should include logs when errors happen, make sure those are actually helpful.

When those two are ready to go, we’ll freeze .4 with whatever other improvements we have. With feedback from users we should be able to fix everything on the list for 3.8.5 (except the visual editor :().

Other high priority things according to the list.

  • #269 – Better support for 2 step. Even if it’s not full support (asking for the auth code after login), make sure the error messages reflect what’s going on.
  • #112 – Duplicate posts on reader
  • #22 – Consolidate accounts/credentials. I’d bet many credential issues are still caused by the fact that some places check for credentials in the wrong places. In a nutshell: WPAccount should be the only class to talk to the keychain, and there should be no [WordPressComApi sharedApi], ask the default wp.com account for it’s APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways..

I’ve ruthlessly moved everything else to 3.8.5, and added a must-have label to indicate blockers for release

#ios

3.8 is finally out ready for iOS7 It…

3.8 is finally out, ready for iOS7.

It feels great to finally come out of the shadows and merge all the code back to our public repo at https://github.com/wordpress-mobile/WordPress-iOS. We’ll be publishing some more branches in development over the next few days.

In the meantime, go wild testing 3.8 and let us know how it goes

#ios

3.6.4 is approved and waiting for us to…

3.6.4 is approved and waiting for us to release. I’ll release on monday because we know better than to release on a Friday 😉

@aerych I’ve created the release 3.7 branch Feel…

@aerych I’ve created the release/3.7 branch. Feel free to commit there and merge back to develop if you want.

There are some changes to be made to accounts/WordPressComApi at #22 but I’m not sure if they’ll be ready in time for 3.7, so I’ll do those on develop

For our next reader release we were using…

For our next reader release we were using relative dates (e.g. 2 hours ago), but these had a few problems:

  • When to update them: easiest, update on display. Not accurate 100% of the time, but almost.
  • That affects performance, since it has to re-calculate the string while you are scrolling.
  • Hard/impossible to translate properly. AFAIK, the iOSiOS The operating system used on iPhones and iPads. translation system doesn’t have support for multiple plural forms. There is a 3rd party library for this, but only solves it for Russian.

Should we use normal timestamps? I have this so far, it’ll show time for today’s posts, then “Yesterday”, then the date. As it’s using the system formatters, we get translation for free.



This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters


diff –git a/WordPress/Classes/ReaderPost.m b/WordPress/Classes/ReaderPost.m
index 32db8ac..f1c62d5 100644
— a/WordPress/Classes/ReaderPost.m
+++ b/WordPress/Classes/ReaderPost.m
@@ -551,70 +551,17 @@ NSString *const ReaderCurrentTopicKey = @"ReaderCurrentTopicKey";
– (NSString *)prettyDateString {
NSDate *date = [self isFreshlyPressed] ? self.sortDate : self.date_created_gmt;
– NSString *str;
+ NSDateFormatter *formatter = [[NSDateFormatter alloc] init];
NSTimeInterval diff = [[NSDate date] timeIntervalSinceDate:date];
– if(diff < 60) {
– NSString *fmt = NSLocalizedString(@"%i second ago", @"second ago");
– if(diff == 1) {
– fmt = NSLocalizedString(@"%i seconds ago", @"seconds ago");
– }
– str = [NSString stringWithFormat:fmt, (NSInteger)diff];
– } else if(diff < 3600) {
– NSInteger min = (NSInteger)floor(diff / 60);
– NSInteger sec = (NSInteger)floor(fmod(diff, 60));
– NSString *minFmt = NSLocalizedString(@"%i minutes ago", @"minutes ago");
– NSString *secFmt = NSLocalizedString(@"%i seconds ago", @"seconds ago");
– if (min == 1) {
– minFmt = NSLocalizedString(@"%i minute ago", @"minute ago");
– }
– if (sec == 1) {
– secFmt = NSLocalizedString(@"%i second ago", @"second ago");
– }
– NSString *fmt = [NSString stringWithFormat:@"%@, %@", minFmt, secFmt];
– str = [NSString stringWithFormat:fmt, min, sec];
– } else if (diff < 86400) {
– NSInteger hr = (NSInteger)floor(diff / 3600);
– NSInteger min = (NSInteger)floor(fmod(diff, 3600) / 60);
– NSString *hrFmt = NSLocalizedString(@"%i hours ago", @"hours ago");
– NSString *minFmt = NSLocalizedString(@"%i minutes ago", @"minutes ago");
– if (hr == 1) {
– hrFmt = NSLocalizedString(@"%i hour ago", @"hour ago");
– }
– if (min == 1) {
– minFmt = NSLocalizedString(@"%i minute ago", @"minute ago");
– }
– NSString *fmt = [NSString stringWithFormat:@"%@, %@", hrFmt, minFmt];
– str = [NSString stringWithFormat:fmt, hr, min];
– } else {
– NSInteger day = (NSInteger)floor(diff / 86400);
– NSInteger hr = (NSInteger)floor(fmod(diff, 86400) / 3600);
– NSString *dayFmt = NSLocalizedString(@"%i days ago", @"days ago");
– NSString *hrFmt = NSLocalizedString(@"%i hours ago", @"hours ago");
– if (day == 1) {
– dayFmt = NSLocalizedString(@"%i day ago", @"day ago");
– }
– if (hr == 1) {
– hrFmt = NSLocalizedString(@"%i hour ago", @"hour ago");
– }
– NSString *fmt = [NSString stringWithFormat:@"%@, %@", dayFmt, hrFmt];
– str = [NSString stringWithFormat:fmt, day, hr];
– }
– return str;
+ if (diff < 86400) {
+ formatter.dateStyle = NSDateFormatterNoStyle;
+ formatter.timeStyle = NSDateFormatterShortStyle;
+ } else {
+ formatter.dateStyle = NSDateFormatterShortStyle;
+ formatter.timeStyle = NSDateFormatterNoStyle;
+ }
+ formatter.doesRelativeDateFormatting = YES;
+ return [formatter stringFromDate:date];
}
view raw

foo.diff

hosted with ❤ by GitHub

Thoughts? We need to figure this out before uploading the new strings for translation

I just added a few things to the…

I just added a few things to the style guide:

  • Indenting to match Xcode defaults
  • Brackets on new lines for method definitions to match Xcode defaults
  • Note about cleaner interface files
  • Constant definitions

Some other things I’d like to see there:

  • Assertions and NSObject-SafeExpectations usage
  • Note about XIB vs coded interfaces
  • Full source for a class as reference
  • Reorder content so the most common mistakes are first

#ios