Comment Re:Free/Libre/Open-Source Software (Score 1) 222
Comment Free/Libre/Open-Source Software (Score 1) 222
Comment Re:YMMV (Score 1) 313
Comment The tool matters (Score 1) 313
I don't see any information on how the students were taking notes on their machines. Just "taking notes on laptops" may mean anything.
I wouldn't be able to take any notes in Microsoft Word or LibreOffice. But in Org-mode I actually take notes more efficiently than I can do than on paper.
Comment Ability to extend, reogranize and search (Score 1) 313
To me the greatest advantage of digital notes over pen and paper is that I can extend a topic when I acquire additional information on it (whereas on paper there's usually no physical space to do that), reorganize them by merging related notes into a single unit and also search through them.
Also, I type much faster than I write and I can shape and transform my notes very easily with Org-mode.
But actually I'd prefer if there was some collaborative note-taking going on instead of the huge duplication of work as it is now. Something like wiki-notes, where the purpose of taking notes would be not to recreate them each time but to make them better over time and update them.
Comment Re:Org mode in Emacs (Score 1) 217
I use Org all the time. I even wrote my masters in it (exported to LaTeX and PDF).
Comment And yet they suggest Chrome (Score 1) 221
Comment There is a better word (Score 1) 46
Comment Re:Criticism from a past MODx user (Score 1) 70
Comment Re:Criticism from a past MODx user (Score 1) 70
Comment Criticism from a past MODx user (Score 4, Interesting) 70
I was using MODx Revolution for around two years, and it has many good sides, about which you can read on their website, in the books they published and in their wiki. But there are also some issues that led me to seeking an alternative now. MODx developers, please take this as an attempt of constructive criticism (and sorry for my imperfect English).
- Too much is stored in the db, and that makes it very hard to work with git. Even with the 'static elements' functionallity one must have the actual 'element' in the database even if the code is stored in a file.
- Poor performance of the backend. The backend is implemented entirely on ExtJS and is slow. Despite it's ExtJS it still requires to reload the page too often.
- Very hard to develop own stuff on top of it. Just take a look at the tutorial on creating an extension (called 'extra'). I've developed different 'extras' to implement custom functionality in my projects, and I constantly had the feeling that they just made simple things much overcomplicated.
- Poor documentation. Just take a look on their API docs. For example, the documentation for the modX::addExtensionPackage() function just says: "Add an extension package to MODX", and no information on the arguments besides what types they are.
- Some serious problems in the core. For example, the widely used function modX::getChunk() has a performance bottleneck and can't be used in anything like, for instance, displaying a big list of products on a page, despite that this is exactly what it's for. If one instead reuses a same chunk object to iterate through a set of DB records (using $chunk->process()), the performance is dramatically increased. This issue has been reported on the forums, but didn't catch much attention (I can't even find the thread now.) The getChunk() function is widely used in some very important modx extensions, and yet the performance bottleneck doesn't seem to bother to the MODx community.
This isn't the full list. This is just some random (but major) inconveniences I can recall right now. To me, MODx is a great idea which for some reason wasn't implemented well.