Blogs

Liferay 7 Milestone 2 - The adventure continues

Jorge Ferrer

October 29, 2014

A Minute Read

It's been around 2 months since Milestone 1 and we are now ready for the second public deliverable of the ongoing Liferay Development: Liferay 7 Milestone 2. As usual it can be downloaded in Sourceforge’s downloads page. If you prefer to get them from a Maven repo you can get it from Liferay’s maven repo. If you prefer to get it from GitHub you can use the 7.0.0-m2 tag.

If you didn't download Milestone 1, no regrets, just read again its highlights and download with Milestone 2. Compared to the previous milestone, this one includes mainly refinement and bug fixing of the new features, as well as quite a lot of work doing refactorings and starting new cool functionalities that will surface in the milestones to come.

One significant new improvement that you can already see in this Milestone is Alloy Editor. Alloy Editor is a new project lead by Iliyan Peychev which aims at greatly improving the user experience when creating WYSIWYG content. It started drawing inspiration from Medium.com and has outgrown it quite a bit. It uses CKEditor under the hood but provides a new UI on top of it. We have started by applying it to blogs (since it's a simple case). Here are some screenshots of how editing a blog entry feels like in Liferay 7 Milestone 2.

1) This is how the editor looks when it's first open:

2) This is how it looks once I've entered a title, subtitle and some content. Look at the plus within a circle. That's what allows you to insert stuff, such as images (which you can also just drag and drop inside the text):

3) If you want to add format to some text, just select it and a nice simplified toolbar will offer the format options.

4) All non-content related fields are organized in a secondary tab called "Settings":

We are very interested in getting feedback on the authoship experience in blogs, since our goal is to later apply Alloy Editor to other applications.

For a complete list of all improvements done in this milestone visit the board: Liferay 7.0 M2 New features grouped by Area.

Send us your feedback about Alloy Editor or any other feature in any Liferay 7 milestone through the Beta Testing forum category.

10 Comments

Please sign in to comment.

Downloading right now.......
AlloyEditor looks very sexy emoticon

This will be my first module to explore in this milestone emoticon

Please sign in to reply.

Thank you Jorge for this amazing news! It's great to see the screenshots; downloading!

Please sign in to reply.

Cool! The new editor reminds me of medium.com.

Please sign in to reply.

Cool... I was waiting for AlloyEditor emoticon

Please sign in to reply.

Good news and congrats for this !
Is it only for blog entry ? It will be great to have this for all new entry...

Please sign in to reply.

I noticed that the html source editor is gone. (At least, I couldn't find it) Will it come back in future revisions?

Please sign in to reply.

That's a very good question Christoph.

We haven't decided yet whether to provide source editing or not. IMO if we do it should be out of the way of normal users. Also I think it should open a more robust editor. One that at least has syntax highlighting and is capable of some code formatting. It should also take the whole screen, not just a tiny portion of it like CKEditor's original UI does.

I'd love to hear your suggestions as well.

Please sign in to reply.

Hello Jorge,
I think that source editor is a must have for Web Content component (even without syntax highlighting and other fancy functions). We use it very often for wide range of "technical" articles like static JS sliders, banners, theme-embedded articles etc. It does not always make sense to create separate structure/template or ADTs for these content, especially when our clent has technical administrators which are familiar with HTML and javascript.

In my opinion, a full screen editor (preferably, whole content editor could be fullscreen) with HTML/javascript syntax highlighting and code formatting is enough. Autocompleting is not required as we usually write the code using other editors (idea, eclipse or even notepad++) and then paste it to CKEditor - formatting and syntax highlighting would be helpful in finding bugs and making quick changes.

Regards,
KG

Please sign in to reply.

I think a source editor is needed. Even the "not-so-html-savy" content editors in our company use it. Usually they just copy a couple of lines from one article to another. Works most of the time, sometimes they have to ask a "tech guy" for help.

The html editor doesn't need to be fancy, but it needs to be there. Even now, a lot of things can't be done in CKEditor (which is fairly powerful) without editing the html.

I also agree with Krzysztof, we also use webcontent for "technical" articles. We simply render them into portlets using JournalDisplay.getContent(...). That way application owners can change the various help texts and images in portlets without redeployment.

One of the biggest problems with source editing are missing closing tags. CKEditor automatically closes them, but often it does so in a weird way, making things somewhat worse. A warning about missing closing div/span/... would be extremely useful, I think.

Of course, formatting would help too in that regard.

Please sign in to reply.

I hope you guys had a nice trip back from the DevCon in Darmstadt. It was, as always, well enlightening.

The new Alloy Editor is really, really awesome. Very nice. Since Iliyan told me that you are happy to receive feature requests, here we are:

1)
Maybe it's a personal thing, but when I tried it, what bugged me is the question: Where does the editor stop and where does it begin?. I mean, here I have a nice box and I type into it. With the new editor everything blends in. I am not such a big fan of the "superflat" style that's currently modern, so maybe it's just me. And maybe this feeling vanishes with more experience with the editor.

Still, I would find a button or something to outline/highlight the editable area(s) helpful. Then I would instantly know: Ah, yes, I can/ca'nt edit that.

2a) Images / Drag & drop
CKEditor allows drag&drop of images into the text in a bad way, it just adds a data:image blob to the text. Many reasons, why this is bad. Iliyan told me, that it's planned to solve this and solve it in a better way. Which brings up the question: Where to store the images?

I guess, in document library. Brings up the questions Which one? (personal or site) and Which folder? "Browse" is really annoying if you drag&drop images.

A lot of users don't want those pesky blog images to clutter the root folder of document library, they want them ordered/categorized/...

So I propose to put those images by default into a blogs folder in personal document library. For people who don't care, it doesn't matter anyway. For a lot of people that don't like clutter, it's a good starting point. Blog images are separated from the rest and probably a lot of people will leave it that way.

I am unsure if it is necessary to select a target location. But it would be nice to be able to select which default folder to use. And for power users, check my info idea.

2b) Images / Info
Add an info button to images and files. It could show things like width/height/date/size/storage location/... and(!) it should contain an option to manage the image, to open the document library and categorize it, move it, ...

That way somebody could drag and drop the images and when he is finished, he can instantly go to document library and do something with them.

3) Where are my images/documents used?
That's a very common question I often face. I often hear: "I can never delete an image/document, maybe it is used somewhere!". When an image/document link/... whatever is added through the editor, please don't add just the link, store the info in some link table in database. Probably it would be helpful to put the fileentryId into the html too, for reference.

If a user manually adds a link you might even be able to calculate the reference. I mean, basically all DL links start with /documents/...
Not a foolproof thing, but it would be a start. It will probably never be possible to fix broken links for good, especially if people are allowed to do source editing. But it still would be an amazing feature.

4) Add ?width=SIZE to the images and enable the servlet
I forgot the parameter, but it's possible to tell Liferay to resize the images "on the fly". Please, please, enable this feature by default. I know editors, who upload 10Mb images and use them as 200px images. And then they complain, that "it" doesn't work, especially mobile.

Well, thanks for reading this wall of text! emoticon

I hope there are interesting thoughts in there!

Please sign in to reply.