27 November 2013, 11:15

I generally agree, markdown has a learning curve that can be intimidating for non-developers. If we added a markdown feature, we'd want to make it be an optional alternative to wysiwyg, not a mandatory replacement.

On the other hand, our currenty wysiwyg editor probably has an intimidating learning curve for a lot of users as well. I imagine the typical non-tech user's eyes glaze over when they see the three rows of tiny icons and menus at the top of our TinyMCE.

Upgrading to the latest version of TinyMCE will help, because they've simplified the default interface: http://www.tinymce.com/tryit/full.php

Or if we can't manage that for 1.9 (because it will be non-trivial), it would probably be pretty easy to just port over Moodle 2.6's TinyMCE menu bar, which condenses the buttons down in much the same way.

Cheers,

Aaron

28 November 2013, 7:46

Here is an example page of how I am setting up the blocks:

http://portfolio.beitmitzvah.org/user/ben/maps

If you look at the section "Map Keys".  The title and text below it are a "text block".  Right below that is an "image block", but if I were to print that section out, I would expect / want the two blocks to be kept on the same page.  Or when I select the title "Map Keys" I would want / expect see be able to "comment" or "edit" those two blocks as one lgoical entity even if they are physically two separate blocks.

The same is true on the bottom section "google map".  The title is a "text block".  The google map is an "external apps block".  The text below the google map is a "text block".  But if possible, when this page is printed out, I would like all three parts to be on the same page.

So basically the isse has to do with printing out either a whole page or sections of the page.  Being able to specify in the print.css file page breaks.  But how do we define the relationship between the blocks.  And as commenting on that section of blocks or editing as a section of blocks.

Either the algorithm could be simple, if there is no title in the header field, assume the block belongs with the block above it.  Or we could have a check box "keep with previous block", "keep with next block", "keep with side blocks"?

As for the images, just implement them the same way that the friendly urls are implemented for pages.  Except instead of it being:

http://portfolio.beitmitzvah.org/use/ben/maps (the page) the image file would be

http://portfolio.beitmizvah.org/user/ben/file/politicalmap.jpg  which could then have markup of 

[politicalmap.jpg]  If it is in a sub-folder, it would be [maps/politicalmap.jpg]

If it is an institution map, it would be [/institution/homeschool/politicalmap.jpg]

Or if a another user shared a file it would be [/user/myfriend/file/politicalmap.jpg]

Group would be [/group/mystudygroup/file/politicalmap.jpg]

Site file would be [/site/file/politicalmap.jpg]

As for needing to know the name of the file vs. using a selection box, it depends on the data.  If a person wants to use 50 maps for the 50 states of the US, one would assume that the images had some type of naming convention when they were added to the database.  But as with wikipedia, sometimes the image names will make logical sense, and sometimes they will not make logical sense.  Garbage in means garbage out.  Logical data in means logical data out.  

Melissa

28 November 2013, 11:35

Ah, yes, our print stylesheet could use some work. :) I see you've been active on the Launchpad bug about this ( https://bugs.launchpad.net/mahara/+bug/692769 ). So, thanks for the helpful feedback there!

Coming up with an intuitive system for specifying page breaks is a little tricky. Here are some ideas:

1. Using the 1.8 flexible layouts, we could set the "page-break-inside" property to "avoid" for each layout row, so that by default it'll try to put page breaks between rows rather than inside them. (There is a hard-coded limit of 6 rows per page, which would limit print layout options a bit, though.)

2. It would probably be really simple to write a manual pagebreak Block, which simply acts as a placeholder to force a pagebreak after it, using this CSS: http://davidwalsh.name/css-page-breaks

Cheers,

Aaron

02 December 2013, 0:31

Looks like there was a plug-in created by Catalyst UK in 2011 to enable export to pdf using wkhtmltopdf. Might this be a partial solution for printing?

https://gitorious.org/mahara-contrib/export-pdf/source/0c759050d4b370e8e4e04c7c1aaf4ef5af96590c:

https://wiki.mahara.org/index.php/Developer_Area/Specifications_in_Development/PDF_Export

02 December 2013, 11:25

I think one of the reasons our CSS print stylesheet has languished, is because there's always been the plan to polish up the PDF exporter and use that when printing is needed.

Though personally, I think getting the CSS print stylesheet working well, would probably be a better solution. Especially because most operating systems now ship with a "print to PDF" option, so if you get the print CSS working properly you have effectively achieved PDF export, but with less additional code to maintain.

02 December 2013, 12:17

Pringing to a hardcopy, image, or PDF all depend on CSS.  

There are a couple of problems with the sytle sheets.  First is that the default font size is fixed (10 pts) when it should be "small" or "medium".  That way it is based on a user's browser settings and not what the CSS designer thinks is appropreiate.

Second, the printing needs to be have the following optionally turned off:

* header (not including the title and author)

* header including the title and author (user retypes these  in the page themselves)

* comments 

Third, there needs to be a way to specify is blocks go together to form larger blocks.  This can be as simple as two check boxes:

* "keep with previous block"

* "keep with following block"

I would also put 

* keep witth right and keep with left

on the list, but that might be more complicated.

Maybe even have 

* float to right

* float to left

The above two would be good for images or asides.

Once those items are in place (with maybe an ability to give the page or collection a CSS class name, eveyrthing else boils down to the CSS file.  And as long as an end user has the ability to assign a CSS page to a document without having to have access to the file system, users can design pages in any complexity they desire.

The designers of Mahara are under the assumption that they have to keep everything "simple" as to not confuse the end user.  But the reality is that the older generation will be confused (teachers and administrators).  The younger generation will be fine.  Knowing HTML and CSS are one of those life skills that every student should start to learn starting in 4th grade.

Melissa

03 December 2013, 14:40

Thanks for the feedback about the CSS, Melissa. I see most of it is already up on the Launchpad bug.

I'll admit I carefully weigh whether each new feature in Mahara is worth the cost of increasing its complexity for end-users (and for the developers to maintain it). It's also worth keeping in mind that Mahara is not just used by young students. It's also used by universities, trade schools, professionals doing Continuing Education requirements, and, yes, teachers and administrators, who may choose to just go with Google Docs if they're evaluating Mahara and it's too complicated to figure out.

That said, it's always a difficult decision as to where to draw the line, so I'm glad to see people's input here on the forums. Hearing about how people use Mahara "in the wild" really does have an impact on what features we decide to implement and/or incorporate.

Cheers,

Aaron

04 December 2013, 11:56

Why is upgrading to the most recent version of TinyMCE non-trival?  Could you please list the Mahara files which are responsible for calling TinyMCE?

I am a software engineer, so I am interested in playing around with upgrading this on my own system.  If I get things working, I will share it.

Melissa

04 December 2013, 14:49

Mahara (like Moodle) is currently on TinyMCE 3.5. The latest version is TinyMCE 4.0. It has different APIs and can't simply be swapped in without updating the Mahara code that instantiates a TinyMCE editor. (I tried.) From past experience, even upgrading from one 3.x major version to another has tended to require a lot of effort to get it working properly.

I believe the main files related to TinyMCE in Mahara are:

• htdocs/js/tinymce/
• htdocs/lib/form/elements/wysiwyg.php
• htdocs/lib/form/elements/tinywysiwyg.php (though this form element is not actively used in core code anymore)
• htdocs/lib/web.php, in the smarty() function

Those are just the most important bits, but not an exhaustive list. You'll need to search the code for "tinymce" to find everything.

Cheers,

Aaron

05 December 2013, 7:09

It looks like the only file that needs to be changed is the web.php file, but I will have to do some testing to verify that.

The base file that is called to instatiate the tinymce is a different name.  The code is also a lot cleaner in the newer version, so keeping it up to date in the future will be a lot easier.

I already figured out the TinyMce wide (how to call TinyMCE in a stand alone HTML file).  Now I just need to figure out how to integrate it into Mahara.

Melissa