[GSoC] Eugene Nikandroff

nikandroff · March 18, 2017, 8:22pm

Hello! My name is Eugene Nikandrov and in this post I would like to present myself.
I am currently a student at HSE university in Moscow, Russia.

Although, I spend most of my time learning about development and creating applications (mostly web). I interned at Intel for 8 months and then at Microsoft for 6 months. I also cofounded a startup project as a full stack web developer.

I am interested in Plone for two main reasons: being able to help and to get valuable experience. As Plone CMS is actively used by lots of people, I would love to work on something what would actually improve experience of many real users. In my case, as I am excited about front-end and UI/UX development, I can imagine saving users time, as they launch their Plone applications, and easing the process of getting new websites up and running. Personally, I could also learn a great deal about developing process in a larger scale applications and in a professional team.

I decided that it would be better to introduce myself after I have some progress. So, I am glad to tell that I have successfully installed and launched Plone. Moreover, I created a dedicated server with Plone at nikandroff.com I think that could be a convenient and easy way for me to discuss and iterate on my projects in Plone by updating it on my website. This would allow my mentors and other Plone members easily see and evaluate my changes in action.

Also, as suggested by Cris Ewing, I found a couple of issues on GitHub and tried to fix them. While trying to fix these simple issues, I think I quickly got a much better understanding of Plone structure. Although, I think I know how to solve the two issues I took a look at, there are some questions that I have. I explained proposed solutions and my questions about the issues in the issue comment section on GitHub. You can take a look at them here and here.

At Plone, I am most interested about JavaScript Web projects. Since my main interests and expertise are UI/UX and front-end development, I think these projects would fit me greatly. I think that I have the competences and the knowledge to achieve desired results since I had good practice with HTML, CSS, and JavaScripts while working on my web projects. I had experience building websites using such tools as Bootstrap, jQuery, and LESS. Although, I love and interested in Python, I am bit afraid that I am too inexperienced in it to be able to create a big project it. However, if a project would not require much of Python, I would be really excited to work on it and learn more about it.

In particular, the most appealing projects to me are Better Diff Viewer for Content and Improved Patterns-based Widgets. Among them, Diff Viewer seems more exciting. However, since I am going to apply only for Plone organization, I would like to apply for both projects.

In this topic I would love to hear feedback and discuss the details of the implementation of these projects. With the help of the community I think I would be able to better understand the nuances of development and, later, create a better and more complete proposal for Google Summer of Code.

1) Better Diff Viewer for Content
Do I correctly understand that there will be two main parts here: 1) diffing HTML text and 2) reusing the edit form for not "inline-diffable" fields?

1.1) Diffing HTML text.
I took a look at Plone editing UI and at history documentation.
Do I understand correctly that there is no UI to compare or go back to previous version of content without working with code?
I also took a look at Wikipedia View history tab. So at Wikipedia, as I understand, there are two pages for working with diffs: a page for seeing the list of diffs and a page for comparison of one edit against another.
How different it is from what what be good to have at Plone? What would be good to have in addition to what Wikipedia has, or what would be extra there for Plone?
Thus, do I understand correctly that this project aims to create a frontend UI for an already existing backend DiffTool logic?

1.2) Reusing the edit form for not "inline-diffable" fields.
Could you hint what would be an example of editing of "a poorly-formatted "code view""?
Should UI from "Diffing HTML text" project be directly applied to not "inline-diffable" fields? What kind of key differences should be made to the previous UI?

2) Improved Patterns-based Widgets
Do I understand correctly that this project is about adaptation of some existing patterns from Patterslib and plone.app.widgets?
So in some widgets the changes would fix/improve existing functionality (data-grid field), and some would add new functions (date and date-time widget, Taxonomy picker)?
What portion of the project do you think would be in Plone Mockup and in Plone Patternslib?
Are the mentioned three widgets are the most prominent examples and are the most likely beneficiaries of this project? How many widgets improved do you think would be a good number for a GSoC project?

Those are first question that I have after meeting with Plone.
I would love to hear your feedback, comments, and ideas both on the points mentioned here and anything else you think is important.
I am looking forward to spending this summer with Plone.

Sincerely,
Eugene

cewing · March 19, 2017, 5:21pm

Greetings, @nikandroff and welcome to the Plone community.

It's clear that you've done quite a bit of preparation. I'll simply mention that for your questions about the diff viewer idea, you'll want to talk to @hvelarde and @jensens, and for your questions about the patterns widgets, you'll be talking to @seanupton primarily. They should be able to answer your questions and set you on the right track for your proposal.

Again, welcome to the community, and thanks so much for choosing to work with Plone for your GSoC experience!

c

hvelarde · March 20, 2017, 10:38pm

No, in fact there is one but seems to be pretty ugly:

Select History on the main view of an item.

Select Compare on the next modal:

You'll see something like this:

regarding 1.2 we should ask @jensens.

seanupton · March 24, 2017, 6:22am

Yes, to some extent. A few years ago, Plone moved to using patternslib (via Mockup project) and creating a bunch of declarative patterns for various interactive or behavioral features -- powered by JavaScript, but leveraged by plain-old-HTML consumers. Some of these "patterns" are widgets, some do other things. The "widgets" bundle of mockup is, for example, just widgets (my Plone 4.x sites, for example, uses this via plone.app.widgets).

When we look at trying to implement widgets, I am looking at this in a very loosely coupled way: we care mostly about the widgets as stand-alone patterns that could be used inside or outside of Plone (though hopefully within!).

That seems correct, though I should clarify:

Plone/mockup ships with a date and date/time widget that could use some improvement; it is based on PickADate, and patternslib ships a different stock date widget altogether. Both have varying merits. I have written a new pattern that wraps the core PickADate pattern to add keyboard-friendly entry functionality, but it is a giant hack (a big wrapper) with an implementation experience sufficient to make me question the merits of long-term use of the the PickADate library. Writing something new that aims to be lighter payload, keyboard friendly, and maybe a bit more flexible on time entry is a good idea; perhaps such effort could leverage the patternslib date picker, or maybe something altogether different. I am not sure, just dissatisfied with what we ship OOTB.
Data grid for compound field entry has never really been part of Plone core, but has been done in popular add-ons for years. The one add-on our community has (collective.z3cform.datagridfield) is outdated and clunky in a variety of ways within the Plone 5 / patterns / modern JS context.
Taxonomy picker: this is a pet wish of mine; there have been add-ons many years back in the Plone world (ATVocabularyManager) to manage tree-based vocabularies (e.g. IPTC subject codes, NAICS, VDEX, etc), but very little to allow tree-based browsing. This kind of functionality is useful for digital asset management, library science, and publishing domains, among others.

Well, new widgets could likely be added in mockup, even if they worked as plain patternslib widgets (e.g. could work outside of Plone and mockup). I think most of mockup's widgets could operate under such constraints. How and where new widget patterns could be developed in relation to patternslib and mockup could be approached in a variety of ways (I might defer to some others in the community with better conceptual notions of what the best practice might be here).

2-3 widgets if we are talking the level of complexity I have been describing in ideas. Things like a data grid and tree-based browsing widget (e.g. "subject picker" for taxonomy) have a variety of possible complex dependencies (not in the sense of external libraries, but in the sense of supporting concepts). Possibly more widgets if lower complexity, but the lower complexity the lower the novelty and higher likelihood of already being solved.

Regarding the complexity.... For example, handing data-grid right might involve greater degree of JavaScript control of per-field/column widgets within the grid, but this would likely need to be configurable such that there was deference to being consistent with defaults that Plone used server-side -- so a configuration piece that uses JSON to configure the grid might also require some server-side adapter or view to translate particular widget lookups (server-side components) to client-side patterns (e.g. whether to use a radio button for a field inside a grid column versus a select drop-down).

I hope this is helpful clarification.

Sean

nikandroff · March 26, 2017, 3:05pm

@hvelarde thank you for the reply! Could you say what version of Plone this is? I installed 5.0.4 and could not find the History link on the main view of an item.
However, there is a "/historyview" tab in the admin window on the left.

After clicking "Compare to the current" there is the following view. It seems that this view may be improved. It seems to me that dark red html parts should not be display in the "inline" option and should be left for "as code" option only. Also, at the bottom of the screenshot, there seems to be a bug with the font size, when I deleted a portion of content.

Also, it seems that there currently only "Unified" view for the "inline" option and "Split" view for "as code" option, to speak in GitHub terms. Is there a proposition to make a "Split" view for "inline" option as well, as it made on Wikipedia (shown below)? It seems to me, that for content creation (in opposite to code on GitHub diffs) "Split" view may be more appropriate.

@hvelarde , in general, I would appreciate if you could point to more specific areas for potential improvement in the history view. Then I could make a couple of mockups for more detailed discussion and iteration on them.

tkimnguyen · March 26, 2017, 4:38pm

I'm sure that's what he meant by the history link.

hvelarde · March 27, 2017, 2:06pm

I need @jensens to answer to your questions.

I think you better use latest branch of Plone 5.1 as there were some issues on the toolbar in Plone 5 and those are already fixed.

jensens · March 27, 2017, 3:20pm

I don't think much has changed for the History view in 5.1. At least nothing I am aware of.

The toolbar link is still the same with this IMO useless modified timedelta.

cewing · March 27, 2017, 4:03pm

@nikandroff:

The main point of this project idea is that the views we use for this, and the HTML and CSS within them, are very very old. What's worse, they were originally written by programmers with little user interface design experience. The goal of the project is to provide views that are more useful and easier to look at than what we have now.

Having a side-by-side comparison (split view) for inline changes is absolutely something that would be good to have. It would also be nice to have a view of "code diffs" that looks better and makes the changes more clear to the end user. Wireframes and mockups of what such views could look like are definitely part of the project and we look forward to seeing what ideas you have about how to make these pages look better!

hvelarde · March 27, 2017, 4:47pm

I think the way the Wikipedia shows diffs could be interesting for rich text fields; we have other field types: what about text fields, tags, images?

take a look at the News Item content type and try to imagine how to display differences on every field out there.

GitHub, for instance, lets you select among 3 different methods on images: 2-up, Swipe and Onion Skin:

file fields will be more difficult to handle and maybe we want to show only the size.

nikandroff · March 28, 2017, 10:16pm

@jensens thank you for the reply! By modified timedelta do you mean the history tab text in the left side toolbar? If so, I personally also think that this element seems inconsistent and unconventional. I think just "History" text would be more intuitive. When the last change was made can be shown below "History" in small font, or can be removed altogether.

Also, do you have any suggestions or ideas on which specifc areas of the History/Diff Viewer can be improved?

Finally, could you tell more about "inline-diffable" fields for Better Diff Viewer for Content project? hvelarde said I should ask you about this part.

nikandroff · March 28, 2017, 10:51pm

@cewing @hvelarde Do you think that it would be a good idea to follow GitHub styling guidelines?

I tried to do some things that could make the interface a little cleaner:

increased line height
removed horizontal lines
highlight of the whole background of the diff
increased width for big screens
moved header a bit
removed the legend
removed header with versions

Additionally, I think that would be good to also add tabbing and syntax highlight.

Here is the original diff.