text:
Type: New Feature
Status: Closed
Priority: Major
Resolution: Fixed
Affects Version/s: 1.9.3, 2.4.1, FRONTEND
Fix Version/s: 2.8
Component/s: HTML Editor (Atto)
Testing Instructions:
Run the entire behat suite. We are looking for any tests that accidentally trigger this "recovery" confirm window.
Open a page with an Atto editor.
Type some text - wait more than 60 seconds.
Leave the page without submitting the form.
Go back to the page.
Verify a small notification shows in the editor and the unsaved text was recovered.
With the editor open, shutdown apache and make some changes to the text. Verify you get a warning after 60 seconds - "Could not connect to the server. If you submit this page now, your changes may be lost.".
Start apache again, verify the warning goes away after 60 seconds.
With the editor open in a page, in another tab, logout the current session. Make some changes to the text, verify after 60 seconds you get the same warning.
Load a forum - make 2 posts. Start replying to the first post, then wait until the "Draft saved" message is shown. Then leave the page without saving the form. Start replying to the second post and verify the draft is not recovered for the wrong post. Go back and start replying to the first post and ensure the draft is recovered because it matches this post.
Another potentially tricky case:
Run the entire behat suite. We are looking for any tests that accidentally trigger this "recovery" confirm window. Open a page with an Atto editor. Type some text - wait more than 60 seconds. Leave the page without submitting the form. Go back to the page. Verify a small notification shows in the editor and the unsaved text was recovered. With the editor open, shutdown apache and make some changes to the text. Verify you get a warning after 60 seconds - "Could not connect to the server. If you submit this page now, your changes may be lost.". Start apache again, verify the warning goes away after 60 seconds. With the editor open in a page, in another tab, logout the current session. Make some changes to the text, verify after 60 seconds you get the same warning. Load a forum - make 2 posts. Start replying to the first post, then wait until the "Draft saved" message is shown. Then leave the page without saving the form. Start replying to the second post and verify the draft is not recovered for the wrong post. Go back and start replying to the first post and ensure the draft is recovered because it matches this post. Another potentially tricky case: Create a quiz with an Essay question in it. Attempt the quiz as two different students. Go to Results -> Manual grading, and select the essay question. Verify that autosave works on the two editors on that page.
- Create a quiz with an Essay question in it.
- Attempt the quiz as two different students.
- Go to Results -> Manual grading, and select the essay question.
- Verify that autosave works on the two editors on that page.
Affected Branches:MOODLE_19_STABLE, MOODLE_24_STABLE
Fixed Branches:MOODLE_28_STABLE
Epic Link:
Pull from Repository:
Pull Master Branch:
Sprint:BACKEND Sprint 15
Story Points (Obsolete):40
Sprint:BACKEND Sprint 15
This emerged during the discussion at
MDL-13370. Shortly: use AJAX to automatically and periodically (eg. every minute) save the content of a WYSIWYG editor to the concepts (drafts) space. See GMail for the working example.
It seems to me that we could use table mdl_post for this therefore not DB changes should be required. There will be a flag for a rich text field definitions that enables this feature. Every WYSIWYG will have to have some uniq identifier. Concepts are accessible to their owners only (and admins?) - maybe via a card in their profiles? Their lifetime is a subject of configuration - couple of hours by default.
Gliffy Diagrams
Issue Links
- caused a regression
MDL-47140 Atto autosave: overwrites your content if an error occurs
- Closed
- has a non-specific relationship to
MDL-47822 Potential improvement to atto-autosave heuristics
- Open
- has been marked as being related by
MDL-38537 Quiz client-side auto-save
- Open
MDL-13370 Let user confirm leaving a page without saving form chages
- Closed
- will be (partly) resolved by
MDL-43434 Moodle form auto-save instead of "unsaved changes" alerts.
- Open
- will help resolve
MDL-48234 incorrect sesskey - occasional failures: trap error
- Closed
MDL-46194 Submission crashes due to formatting errors
- Closed
MDL-14963 Quiz Autosaving Feature
- Open
MDL-15220 Alert user when hitting browser's Back button while in essay textarea with HTML editor
- Open
MDL-16732 Add Forum Auto-Save and/or "Save without Posting" button
- Open
MDL-15855 Give users the ability to save draft versions of forum posts
- Closed
MDL-37980 Removal of auto-logout
- Closed
- All
- Comments
- Work Log
- History
- Activity
- Links Hierarchy
By Olli Savolainen at http://moodle.org/mod/forum/discuss.php?d=74710 :
"A similar thing could be done, yes, for forum posting, too, or for that matter any other form field. Since Moodle uses YUI instead of prototype, it should be done with that, and probably we should try to make it more general than just something that works for quiz or for forum; i.e. this kind of functionality should be integrated in the editor itself and a general backend to receive the autosaves would need to be created."
I've got first working prototype of autosaving. At the moment it can support all form fields rendered by print_textarea(). There are several important aspects to be discussed:
1. at the moment, I save the content of the field into the table 'post' where module is 'autosave'. Is it ok?
2. how shall we implement a recovery procedure? i mean - what the user has to do to get the autosaved contents? I can see two possible approaches:
2.1. add another tab into the user profile where she can find all her recent autosaved fields. This is easy to implement and might be enough given that autosave feature is just a backup&rescue tool
2.2. after the page with a supported field is loaded, try to check if we have a previously autosaved content and offer it to user. This is more difficult to implement. How to make sure we are at the same page again? URL may have changed since the field was autosaved...
This is a valuable feature, but ...
1. I don't think that the post table is the right place for this. Make a new table specifically for this purpose.
2. Recovery should be as transparent as possible.
3. If this is worth doing, surely it is worth doing for all form fields.
4. What does this do to server load. For example it is not much good auto-saving data during a quiz attempt, if the result is to overload the server and crash it when otherwise everything would be fine.
5. What are the security implications. For example, if an malicious person can insert arbitrary content into the admin's autosaved fields area, then when the admin goes to look at that content, he is vulnerable to XSS vulnerabilities. Of course, the more validation you try to do, the more the performance implications.
6. Whatever happens, we need an on/off switch in the admin settings, so admins can control this.
7. What are we actually trying to achieve here anyway? Are we saving people from browser crashes, session problems, server crashes, what?
Thanks for your "buts", Tim.
re 1. I have chosen the current post table because they are simply there and ready, which makes the development and testing much much easier (no need to upgrade, bump versions etc.). I will keep in mind that the physical storage can be change in the future. However, all I/O operation are wrapped so it won't be hard task to rewrite this part.
re 2. well, it matters. I understand this feature as a rescue tool for users whose browsers do not cache the content of our HTML editor. Moreover, because TinyMCE does not update the content of the textarea it is linked to automatically but at the moment of saving the form (using tinyMCE.triggerSave(} call), the browser has nothing to cache. So, I do not think we really need a transparent recovery. Ask somebody who spent half an hour writing a forum post, then lost the focus of the editor (by a popup for example), returned back (after closing the popup) and pressed the backspace because of a typo. He is redirected to the previous page and after returning back, the HTML editor is empty. Such user will be more than happy if he is able to find a minute old draft of his post anywhere in the Moodle, without the need to get the content automatically. Of course, I would like to see a transparent and silent recovery more, but it makes the whole mechanism more complicated. I like things simply stupid.
re 3. sure it is. Let us start with the support of HTML editor. Usually standard form fields are pretty well cached by the browser itself and the input is not so long.
re 4 + 6. totally agree. Admins will have to enable this feature and set the frequency of the autosaving (influnce the server load) and the draft lifetime
5. a priority issue, of course. That is why I wanted to put automatically saved drafts into a user space, ie. his profile. No automatic pre-filling of forms from drafts. If I loose something, I will find it in a rescue box at my profile page. Should standard sesskey() validation be enough in this case?
7. see the users' stories in the linked issues. Basically this should protect from browser crashes, accidental redirections, window/tab close, connectivity problems, server crash etc. Actually I can't see the point of this question.
Well. After submitting the previous post I repeated some tests to be sure and realized that maybe my arguments are useless. TinyMCE in HEAD is cached in my FF3 when navigating to the previous page and back again :-/ It does not work with the current editor (HTMLArea is it?) in 1.9 stable but does in HEAD. Hmm... much ado about nothing? I will test IE and Opera yet. Can some Apple fan try Safari please?
Regarding point 7, there is also simply forgetting about a tab you've been working on and shutting the browser. I've done this three times in the last two weeks whilst writing long schemes of work into a wiki and it's driving me nuts.
It occurred to me that it may not be obvious to people that they have a saved draft at all (new feature may not be widely publicised by admins), which would be a real waste of a great feature, so it might be handy if there was some visual indicator e.g. an 'unsaved work' icon next to the item on the main course page and also within the activity itself.
What about implementing this through the Moodle form API? The form could have a unique ID (perhaps just use the form's class name?), which is saved with its data into the database. If the form is loaded and there is info for that user in the db, then automatically load the form with the data or ask the user if s/he would like to load it with the data. On submit, the data in the database gets cleared. This route would be transparent for users and turn the form API into an even more powerful tool for developers.
I would also suggest using the YUI since it is part of Moodle's codebase and it is relatively simple to have it submit a form's data to a URL. Also, it has a nice event listener API that's very helpful for this sort of work.
A note on performance, one way to help reduce the number of saves is not just by doing it periodically, but also not saving while the user is typing because as soon as you save, it is out of date anyways. You can accomplish this with timeouts by setting one when you detect a change in the form, and then if you detect another change before the timeout has come to pass, then clear/cancel the old timeout and set a new one.
IMHO the form's class is not enough here - the autosave ID should combine the field id and the URL. But in theory the URL may change while still pointing to the same page where the draft was saved.
Yes, the current implementation is based on YUI.
Hmm, I don't think it is good to wait for the user stop typing. It means that the work of "quick-typers" is never autosaved. Instead, there is no need to send an update call to server in case of no change. We could do some statistics based on moodle.org logs: how long does it take to write an average forum post? Ie. the time from displaying the form to the submitting.
"IMHO the form's class is not enough here - the autosave ID should combine the field id and the URL. But in theory the URL may change while still pointing to the same page where the draft was saved."
What about using $CFG->pagepath? On the other hand, I wasn't necessarily thinking that we would just enable autosave automatically for every form in Moodle, might be better to have devs implement in the necessary areas. In which case, the dev could assign an appropriate ID. Just another though.
Yes, that might be a solution. Of course that fields that should be autosaved will be manually flaged by a developer. I was thinking of forum post bodies only at this moment and there should be no problem identifying such fields.
Re screenshot:
1 'Saving' should prob. be 'Saving draft' or even 'Autosaving draft'. Don't want to scare users into thinking it's already been submitted.
2 The saving text should be much smaller
I like sam's idea (from the jabber chatroom):
(15:29:09) sam: can it store the page id (mod-forum-editpost or whatever) and then when you go to that page again (any forum post), display a little '1 recent autosaved draft is available' thing that you can click on to see it and/or get it back somehow?
More screenshots to demonstrate the current implementation:
1. after the page is loaded, an AJAX based check is performed to get know if there is some previously autosaved draft
2. if no saved draft is found, the autosaving feature is enabled and the field content is saved every xxx seconds
3. if there is a draft found, an information appears (with a "yellow fade efect" to draw user's attention) and the draft can be restored with a single click
The actual state of my patch has been attached as autosave-alpha1.diff.txt. Any comments/review/suggestions etc. warmly welcome
Stopping progress on this for a while. Petr informed me there are some planned changes in the HEAD leading to introduce a new form element. The element will integrate wysiwyg editor, image uploader and attachment uploader. It looks reasonable for me to wait for this component to be included and than support autosave of it.
David - can you check http://moodle.org/mod/forum/discuss.php?d=130005&parent=569051#p569547 and http://code.google.com/p/tinyautosave/
TinyAutoSave plug-in works very well in moodle 2.0 (for textareas of tinymce) as an additional / optional autosave feature (should be possible to enable/disable from administration of course)
I would still very like to see this in 2.0 if it's not going to be very hard to do.
The purpose of TinyAutoSave is just to prevent from accidental navigating away from the page (by clicking a link or pressing Backspace button). The disadvantage is that it does not store the draft on the server so it is not the same concept as discussed above. But the advantage is that it does not store the draft on the server so there are no performance/bandwidth issues.
This issue requires some decisions on the required functionality so that we decide about the target version.
1. Should the embedded media and attached files be autosaved, too? I am not sure our File API can support this at the moment. What file area would we used? What would be the context of the files? And itemids?
2. Should the draft be saved on server side or client side?
I think that saving the draft on the server is a better solution, as this will protect the draft from getting lost if the user's computer crashes.
A case that is occasionally reported to us here is that students start typing their post, but then for whatever reason their computer crashes.
This means that they have to log on again, potentially on a different computer, and in our particular case on a computer that has been deep-frozen. As such, any cached drafts will be lost.
I think that if the draft was saved on the server, the user could then pick up where they left no matter if they switched computer or not.
It is a difficult question. A network connection failure at saving time will probably cause the text and the draft to be lost.
I guess saving it simultaneously local and server side is not an option ?
Server side and/or client side solutions could be used at the same time - current core autosave plugin of tinymce has supported local storage methods since January (no more need to download separate TinyAutoSave plugin anymore) - moodle 2.0 should just be upgraded to use the latest version of tinymce (3.3.6) and moodle sites can add/enable client side autosave feature in init code for those textareas that use tinymce with possible functionality settings http://code.google.com/p/tinyautosave/wiki/Functionality . Autosave plugin supports all the browsers that tinymce supports.
The primary solution for temporary autosaving user input data might still be a server side solution as far as it can be used and we might need a setting to administration to be able to enable/disable either one or both of these options. In my opinion it does not need to be too complex (at first), the most common failure is that users accidentally press some link or button that moves them away from editor screen or they press some button that closes window/moodle. HTMLArea has failed to keep input data in such cases, tinymce with autosave plugin can in most cases restore the last data.
Keeping track of user processes might be usefull for other purposes as well - for example Version control here in tracker offers a nice way to track back last changes in files and in Wiki it is useful to find the last changes saved by different users. The main difficulty in autosaving data is in my opinion the choice of deleting unnecessary data - particularly duplicate files - as soon as possible
So if we need to autosave also attachments (clone attachments) clones should be deleted immediatelly after the actual data & attachments have been saved (or small hosted sites run easily out of hard disc space
Re-triage: this must be re-considered for some future version, not in stable.
Please bump this feature request to a near Moodle release. A lot of Web 2.0 applications support auto-save by now, Moodle can't stay behind on this. This request crops up every now and then on the work floor.
I am new for moodle development and hope to participate gsoc 2012. I think we can use AJAX support to implement this feature. Autosaving is done in background and we can specify the way it should be saved (auto save per minute or when some events are triggered by html elements). I think it is easy if we can add new a new table to store those auto saved items. In that table we can specify user id, last edited time, edited url, data.
In data field, we can store values of those elements as key value pairs
eg: (element1 Id: value),(element2 Id: value) likewise
From url we can identify correct position.
We can extend this structure to even forms in the applications.
Those auto saved values are shown in different color so that user can identify it.
Any ideas?
Dimuthu, thanks for considering this for the GSoC project. The HTML text contents itself is not a big issue. Earlier in the 2.0 development branch (before TinyMCE and the new Files API were integrated), I already had a working prototype for that. But the real issue here are files - embedded media and attachments. While editing a form, they are stored in a temporary draft file area and we need to come with a solution, where and how store these files during the lifetime of the form draft/concept. This is the real challenge of this project. It requires deep understanding of the Files API and TinyMCE integration in Moodle. The rest is just fun with YUI and AJAX
David, thank you for reply In the case of uploading attachments and media files I think major issue is having enough server space for that drafts. Now I'm looking at the areas you have explained. However I have some ideas about managing those files.
1. Allowing maximum draft file storage size for each user (about 20 MB). If it is exceeded old files are deleted and gives chance to new files
2. If the draft is not reused for some period those drafts are automatically deleted.
3. Using external server space to store those files. It will reduce the external load on moodle server.
What about skipping the server side storage and using a prebuilt html 5 localStorage API like http://garlicjs.org/ ?
Bumping this issue as a possible UI improvement for the FRONTEND team to focus on for Moodle 2.6. Lots of different ideas and possible solutions, but anything would be an improvement.
Although, a downside to using HTML local storage is that the user has to hit a confirmation approval before a website can store anything in their browser. Which is potentially very annoying and can cause confusion if they say "No", but later want to enable it.
Mark had this working a while back https://moodle.org/mod/forum/discuss.php?d=191050
I'll make sure this gets included in the "Editor upgrade project" for FRONTEND in 2.7.
I like the idea of keeping it simple and using client-side storage. Even if (worst case) it was without the embedded files support initially, it would still be very useful to people.
I've created a proof-of-concept atto plugin for this. It's still not complete and I'll work more on it after the 2.7 release.
The plugin can be found at https://github.com/andrewnicols/moodle-atto_storage
Note: It currently does not deal with embedded files at all.
Looking at that POC it seems the the privacy of the local storage is not considered.
From a philosophical point of view I think the 'browser session' should be protected by the user. From a practical point of view Moodle is often used in a shared-browser environment so we need to deal with this. One solution of the top of my head is that we could encrypt the data with a secret stored as a user preference.
Yup - I'm aware of that limitation at present and it's one I've been considering how best to plug. The problem is that there is no native cryptographic encryption in JavaScript, and even if there was it would inherently unsafe (see http://www.matasano.com/articles/javascript-cryptography/ for a pretty good summary).
In reality someone would have to be actively and maliciously trying to steal data from the store, and have the key (fairly easy to get if we're talking non-SSL), or manipulate the page in some way in order to get the key or data (again, non-SSL or a direct browser attack). However, if someone can access the key in this way, then any way in which we store the data (e.g. AJAX queries to store in the DB) are also probably affected, and we will generally lose against a direct browser attack (that's to say a browser plugin hijacking data for example) so we would be no worse off.
There is one main user-space Crypto suite - The Stanford Javascript Crypto Library (SJCL - https://github.com/bitwiseshiftleft/sjcl) but I need to look at how best to include it. It is compiled with ES6-style exports so I should be able to convert it into an ES6 YUI module now that we're on 3.15.0, but that's still beta code and pretty new. There is another way that I can include it, but I haven't had a chance to try implementing it yet.
But rest assured, this is something I intend to address though before I create an official release of the plugin.
Lets be clear about the 'attack scenario' I am referring to, because it is confusing the issue by talking about SSL and the security of ajax data transmission.
- Teacher 'Bob' uses shared browser in a university library to make a correction to their upcoming quiz questions
- Student 'Dan' sees the teacher on that workstation and uses it after the teacher
- Student 'Dan' uses the localstorage inspector to collect next weeks quiz questions before other students
Yes - that's my understanding too. The attack comes in two forms:
- someone has installed a browser plugin to inject additional code, or retrieve the key - this is a problem regardless and affects everything anyway so let's ignore it;
- someone on the network sniffs for the key or manipulates the HTML during transmission to add additional code - again, this is already a concern, but only for sites not running SSL.
The real difference here comes that we're now talking about data which may not be transferred over the wire so an attacker could sniff for the key, then see what content was left partially written.
Mostly it's not a concern though because the attacker would just be getting access to data they already have access to.
I should point out that on form submission, it nullifies the storage anyway so unless Bob makes his changes, then closes the browser without saving the changes, they won't be there anyway.
Also your attack assumes that they're using the same browser, on the same user profile but this is of course a possibility.
Either way, I do intend to address this wth the SCJL library.
Unassigning this issue from myself in case someone else on the sprint wishes to work on it before I get the chance.
Commenting about my offline thoughts and discussions.
It seems to me that before we go down the track of finding a solution, we should make sure we are all on the same page and understand what problems we are trying to solve. For instance, which ones of those user stories are we facing? (Maybe all of them)
Ann is the teacher of Math 101. She is currently writing a rich document using the page module. Ann is clumsy and by mistake she hits CTRL + W, and confirms that she wants to leave the page. She is horrified seeing what she has just done. But as it gets late, she decides to go home. As she gets home, she logs back into Moodle with intention of starting her document from scratch. She creates a new page resource, and as the page loads a prompt asks her if she wants to reload the draft that she was working on. She clicks 'Yes' and her previous work is restored, including her images. She finishes the document and makes it available to students.
Eric is a student of Math 101 and is submitting an online text assignment. As he finishes writing the assignment, he clicks "Save" but he appears to be logged out of Moodle. He logs back in and navigates to the assignment submission form. His unsent assignment is visible there and he simply clicks "Save" to really submit his assignment this time.
From a public library Daniel is participating in a forum of Math 101, but as he was answering a discussion he realises that he has to run. His post not being ready yet, he uses a draft feature to save the content of his post and retrieve it later. When logging into Moodle from home he reloads his draft, finishes his post and submit it to the forum.
Mary is using Moodle to write a blog post about her Math 101 course. So far she has written a few hundreds words, added images to her blog post, and is fairly confident that it is ready to be published. Unfortunately a power cut occurs and her computers goes down. When the power comes back, she now uses her iPad to log back into Moodle and is happy to find out that her content was somehow saved. She publishes her blog post instantly.
Depending on which ones we pick, we will have to handle:
- Drafts saved cross browsers
- Drafts saved in case of session expiry
- Drafts saved per user request
- Drafts saved when connection is down
Which have different implications:
- The privacy of a draft content stored offline
- The load on the server when sending the content back and forth
- Handling diffs of content to save bandwidth
We will also have to put thoughts in:
- Clearly identifying the page/form/field on which the user is inputting content (the URL + form ID + element ID is not always enough)
- Making a solution that works across editors
All stories are nice features to have, but if you need to prioritize, I think Mary and Eric are the most important once to fix: loosing work because of technical problems is a terrible user experience.
The Mary story are two use cases in one: she could redo her post on the same computer or on a different one when the power comes back (to store locally or not to store locally).
Great question Fred, I agree with Koen's comment.
Some reflections based on your technical prompts:
The privacy of a draft content stored offline
It strikes me that for the sake of privacy, the best thing we can do is only use local storage in exceptional circumstances - when we can't save a draft to the server due to connection/session problems.
The load on the server when sending the content back and forth
Handling diffs of content to save bandwidth
My advice would be to avoid premature optimisation with both of these.
The extra load on the database is worth considering. But In short, do a small number of limited database queries and let the database server do what we pay it to do. It should be possible for most setups to deal with this comfortably and from what we know, they are doing with quiz-autosave which has the very worst of concurrency. Where we get into major problems with Moodle performance is when we start doing 100s of queries per page, or complex expensive queries. This isn't one of these cases.
I think diffing of text content is a misnomer when you consider the relative size of one image compared to gzip'd text content, I wouldn't even consider it.
Clearly identifying the page/form/field on which the user is inputting content (the URL + form ID + element ID is not always enough)
Yup. Agreed, this is very tricky. Edit: and you didn't mention images storage
Making a solution that works across editors
Would be nice to write the server side with this in mind, but I don't think it should be a priority.
About to start working on the Atto version of this.
My early thoughts are:
- No visual indication is required on save - that's just distracting noise
- Local storage has privacy implications - it may be useful in cases that the server goes away and comes back (wifi) - but I think that should be a "stage 2" improvement and there are lots of ajax calls that could fail if the wifi goes away (ie just fixing this one thing does not mean that Moodle works offline)
- Images are already on the server (in the drafts file) so it should be a case of copying all the images from the previous draft folder to the new one when the draft is "resumed"
- Lets just do this for Atto first - the server side should consist of just a small ajax script to do the save / restore
Things not clear to me at this stage:
- how to identify the form instance (userid, formid, context, component, itemid)
- how often to trigger a save (maybe every 5 seconds - only if there has been a change to the content)
Also - not clear is if this should be added to Atto directly or written as an Atto plugin (Adding it to the toolbar seems clunky if it has no buttons).
Damyon, many or your early thoughts are things I worked out (finished thoughts) in the quiz autosave code. I suggest you read that code, and don't re-invent the wheel.
Also, no point both quiz autosave and atto autosave saving the same text. You will need to work out how to prevent that.
Thanks Tim,
Yes - I will check the quiz auto save code.
I guess there will need to be an option per-form to disable this autosave so that it can be disabled for the quiz.
Here is a start.
It saves the text every 5 seconds (only if it has been modified) and relies on the draft files still existing in the previous draft area (they are copied to the new area). The "Key" is the (elementid, pageid, userid, contextid). It is possible to disable the autosave by passing 'autosave' => false as options to the editor (and this is done in the essay renderer and the question behaviour renderer).
Running behat against this now to see if the new confirm is accidentally triggered anywhere.
Behat failed:
(: failed steps (:
01. The "(//html/descendant-or-self::*[@class and contains(concat(' ', normalize-space(@class), ' '), ' mod-assign-history-link ')])[1]" xpath node is not visible and it should be visible
In step `And I click on ".mod-assign-history-link" "css_element"'. # behat_general::i_click_on()
From scenario `Edit feedback for a students previous attempt.'. # /home/damyonw/Documents/Moodle/instances/im/moodle/mod/assign/tests/behat/edit_previous_feedback.feature:8
Of feature `In an assignment, teachers can edit feedback for a students previous submission attempt'
No visual indication is required on save - that's just distracting noise
I am not sure you should dismiss this so readily, I think it has a use, even if its just a psychological reassurance that users can feel safe writing a long post. Given that they previously might've learnt not to trust that text box I think there is even more rationale to give some indication that this is now happening.
I tried to Google Docs/ Gmail, Wordpress and Apple Pages web version and they all gave some indication when a save had happened, so there is also some existing precent for this. Note I also tried github when creating an issue, which didn't give an indication - I didn't expect my content to be there, but it was there when I went back to create the issue.
So my arguments in favour of this are:
- We are trying to actively change user trust of the fields/our software
- Jakob's Law of the Internet User Experience
- Its useful for promoting Moodle/atto if the feature is more prominent. This way people get a warm glow about it when they don't need it rather than the rare time they do need it
Thanks for working on this Damyon.
Some randome thoughts on the patch as it currently stands:
- I think the 'concurrent access from the same user is not supported' restriction needs to be addressed. I think drafting two replies for the same forum in two different browser tabs is a fairly common use case. (At least, I probably do it a couple of times a week on Moodle.org.)
- Since you have to get involved with draft files id, can you use that to distinguish instances? ... No, I guess not
- I don't think a huge, mulitiply nested if, is the nicest way to structure autosave-ajax.php. I suppose I should not just criticise without suggesting something better. I think that autosave-ajax.php should just have the minimal requiest parsing code. It should call methods on a class to do all the real work. That would make it easy to unit-test the important PHP code.
- manual_comment_fields. Manual grading does not happen during the quiz attempt, which is the only place where quiz auto-save happens, so you should probably revert the change in question/behaviour/rendererbase.php.
- I would not hard-code '5 seconds' in the table comment.
- 'Disable the autosave because quiz has it's own auto save function.' - note that you have two very similar comments, but with unnecessary differences. Anyway, you could clarify this to make the first one say 'text-editor autosave'.
No visual indication is required on save - that's just distracting noise
I think we need to either indicate success (thus reassuring the user that they can trust Moodle not to lose their data) or indicate failure (thus warning them that something is wrong and that they may be about to lose data) or both.
If the ajax autosave is failing that probably indicates that, if they hit save, they will lose data so it might be worth displaying something that conveys "connection lost".
-1 for indicating success (that's just like saying "everything is awesome" over and over again - annoying).
However I do agree we should do something about errors - this is an indicator that they are about to lose some data.
We discussed how to present a notification in this case and came up with this mockup. The goals of this mockup are:
- Needs to be obvious which editor the notice relates to.
- Needs to be visible when either the top or the bottom of the editor is not in view.
- Needs to not cause the page content to jiggle.
- Needs to be accessible.
- Needs to not steal focus or require any interaction.
For a server-based version, I could see a very little ajaxy spinning icon somewhere while it's saving, with a tooltip on it that says "Auto-saving draft..."? And not more than once a minute, I think. Losing even 60 seconds of typing is really not a big deal and we don't want to hit the server unless we need to.
For a client version of course it can be more often and I agree that any kind of moving feedback every 5 seconds is likely to be quite annoying. Possibly a little static green light that remains green while everything is OK (with a tooltip "Autosave of drafts is active"). It would turn orange when there was a problem (tooltip something like "Drafts are not being saved automatically").
Andrew pointed out it should be possible to avoid the initial ajax request.
+1 for Martin's suggestions. Just a LED like status green icon for client side, and common AJAX wheel and text while saving the server side. IIRC, Google docs do actually display "Saving..." or so in their top middle notification area. I did not personally find it distracting.
I love the way you are all going through the same design process we went through with quiz auto-save. Please confirm that you have acutally looked at that?
Note that Google uses a very light grey to show 'Saving ...' which I think is good. You really don't need it in-your-face that the save worked. You just been to be able to find the confirmation if you need re-assurance.
Also, should we not be thinking in terms of elements. What I would copy is the dependency information on plugins overview page.
That could go just along the bottom of the editor. (Though, this is were we wish Atto had a status bar.)
Although, with quiz auto-save we reached the same conclusion as Andrew: 'If the ajax autosave is failing that probably indicates that, if they hit save, they will lose data so it might be worth displaying something that conveys "connection lost".' Hence the way that is displayed is quite promenant. More that just a little line of red text.
I would also diagree with some of Damyon's requirements https://tracker.moodle.org/browse/MDL-18014?focusedCommentId=298670&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-298670. If you remeber that the editor content will only changed when the editor is focussed, some of them are not acutally required.
If we add a notification system to Atto - it needs to meet all those requirements Tim. It would not just be used for this one thing.
Personally I've not seen quiz autosave in action ... I just made a small quiz in 2.7 using TinyMCE and I can't see anything on the attempt screens ... and I looked at MDL-14963 and I can't see any design documents at all. So, if we're going to refer to it, then it would probably be helpful for someone to post a screenshot or video showing what it's supposed to look like.
MDL-14963 has two subtasks, of which the one done so far is
MDL-38538 (server-side autosave). However, that has no user-visible UI. The only user-visible bit was added in MDL-42504, which links to
http://docs.moodle.org/27/en/Using_Quiz - there is a screen-grab there.
We shoudl consider moving that disconnect warnig out of the quiz, and making it a core thing that can be used wherever it is needed. Presumably it should be an element.
We realised when thinking about quiz autosave, that really if you don't have a working connection to the Moodle server, you don't want to do anything else until it is fixed, becuase you can only lose data that way. Hence a very promenant warning is right.
OK, thanks Tim.
So quiz has no feedback at all when auto-save is working, and then a very prominent failure notice when it isn't, because we assume there is a good possibility that this is because the network is down and that an ordinary manual save would also fail. Seems reasonable to me.
Who feels strongly about having a success indicator as well?
I wouldn't say that I feel strongly about a success indicator but there is a valid reason for having it.
If we do not have a success indicator how will users become aware that this functionality even exists? I mean, presumably if their browser/computer crashes and they return to the page they will be pleasantly surprised to see their lost content resurrected. That is all well and good but that will only happen to a very small percentage of users. Almost from a marketing stand point I suppose, there is some value in making the user aware of the safety net we are providing even if they never need it.
I think that trying to market a feature is a very bad reason to pollute the UI.
Why exactly do users need to know this exist if it is working normally? How should that affect their decision making?
Why exactly do users need to know this exist if it is working normally?
Like I said above, to reassure them and change their behaviour to trust that it will be saved for them.
The main reason I can think of is that it might save some wailing and gnashing in the case that something does go down. They'll know they just need to go back into the same forum and start a new post and they will find all the old text waiting, right? Otherwise they might just give up ...
The notification doesn't need to be constant ... it could be a small initial notice "Drafts are being auto-saved" that fades away perhaps?
On the other hand I don't feel strongly about this and perhaps we could add it later based on feedback.
On the other hand I don't feel strongly about this and perhaps we could add it later based on feedback.
Or perhaps we could remove it later based on feedback. I think it's only fair to notify users that the draft is being auto-saved. If nothing else then only to avoid surprises when they eventually change mind and decide not to publish that post they started to type; and then they come to the same forum again. The need to know why their previous post is still there.
At the point when they return to the forum they will get a clear messaging saying that an unsaved draft has been found and do they want to recover it.
Just to note that Twitter does completely silent saving, and restore when you go back in (without even asking, but then the twitter UI is simple enough that they probably don't need to ask).
While I appreciate your concerns about complicating the UI Damyon (and luv your work here's a use case where a "saved" indicator would have been really appreciated. Yesterday I was asked to add some words to a collaborative MS Word document on live.onedrive.com. After spending half hour doing this, I had to close down the laptop and move to yet-another-meeting. Moment of anxiety - as far as I could tell there was no indication that my work had been saved, so I copied and pasted the whole lot into an email to myself. I really would have preferred to have had the confidence that my work had been saved before closing down that browser.
Who says I'm paranoid?
I think that trying to market a feature is a very bad reason to pollute the UI.
Its not about marketing a feature, its about marketing Moodle.
This is the reason that cars have airbags and why car companies make sure to tell you about them. It makes zero difference to Toyota if you die in an accident but you knowing that systems to protect you exist changes how you feel about the product. It doesn't matter that 99% of people will never need them. 100% of people gain a psychological benefit from simply knowing that they are being looked after. You do however have to know that these safety systems exist for that to happen.
What places are possible, Damyon, if we're thinking about possible unobtrusive locations for some sort of positive feedback? Can Atto plugins spill out of the actual editor area?
Worth noting the gmail system in the footer of the editor:
"Saved" – shown after a save is successful and while the editor contents = saved contents
"Saving" - during the process of updating save buffer with new editor contents (in a typing pause, or every 10 seconds)
" " - during the time when your editor contents are ahead of the buffer (ie while typing)
This does work pretty well ... but I can't see room for that within the ATTO UI itself, and hanging it off an edge would just look fugly.
Guess I'm returning to a small coloured dot or corner-triangle somewhere that changes colour ...
Otherwise one small quick temporary notification that pops up when you start editing: "This text is being auto-saved..."
I'm totally with Andrew Davis comment.
If you want to make it mega-subtle, you could copy the apple approach and put some text in the titlebar.
When I get back to looking at it I'll do some screenshots of alternatives.
So the current solution in this issue is this:
- do not show any indication when auto-saving
- if there is an error when auto-saving show a big obvious warning
- if returning to a form with autosaved text show a big modal "confirm recovery" dialogue
I think this version is ready for a peer review - I'm running behat on it now to confirm it doesn't trigger any bugs.
Fails against automated checks.
MDL-18014 using repository: git://github.com/damyon/moodle.git
- master (branch: MDL-18014-master | CI Job)
Hi Damyon.
I'll start by repeating myself, having played with what you've done I still wholeheartedly believe we should have something which indicates autosave is happening. Not in your face, subtle but allows some reassurance/builds trust. This is more important to me than the actual feature.. But ignoring that..
1. This dialogue make me have to think:
A previously unsaved version of the text for field "{$a->label}" was found. Do you want to recover it?
Recover / Cancel
a) It's not clear if 'cancel' is destructive.
b) The label for the text field was a bit meaningless in my testing (it might be 'message' - but thats just the same as 'text' really. Tricky, so I have to wonder..
c) Is it really worth presenting a dialogue, should it not just restore it? Could we provide an non-modal dialogue for dealing with these drafts in a button?
d) The titlebar was way too big (on safari)
2. I got the 'autosavefailed' message once in my limited (2/3min) testing on my local machine. Hopefully it was just a blip - but I wouldn't expect blips on my local moodle host.
3. I think that AUTOSAVE_FREQUENCY could be configurable - it would allow admins to reduce the impact of it but keep the feature. Or make save more frequently (as I think the impact will be negligible on moodle servers)
4. messageTypeIcon = '<img width="16" height="16" src" - any reason to hardcode these?
5. I think this line is confusing:
var draftid = -1, optiontype, options = this.get('filepickeroptions');
6. Have you done much testing into how effective the means of identifying the editor is?
Otherwise it looks good
Thanks Dan - I have pushed an update which adds a notification when the text is saved. The frequency is now configurable and the text is always recovered if found (no dialog). If the text is recovered, a notification is shown instead.
This covers 1-5.
I think 6 is not right yet. E.g. grading students in mod assign does not distinguish between the students (so you could have text recovered for the wrong student). Same in forum - it doesn't distinguish the post/discussion.
I have pushed an update which adds a notification when the text is saved.
I would advocate something more subtle than that (Also, I think it would be nice to have a bit of Y.Anim fade in and out so its less jarring.)
I much prefer the restoration behaviour now and I like the notification for that too - it looks slick.
Sorry, but I'm also going to put in my veto on this at the moment. There are some issues with the JS coding that I've noticed:
- https://github.com/damyon/moodle/compare/37c2490aa365c56b9b396fefe7c4b1f919ebf201...MDL-18014-master#diff-32edad94bae57ff6f456d9720ce62100R48 - Integer is not a type - use Number (multiple occurrences)
- https://github.com/damyon/moodle/compare/37c2490aa365c56b9b396fefe7c4b1f919ebf201...MDL-18014-master#diff-32edad94bae57ff6f456d9720ce62100R140 - I'd prefer to see this as an attribute with a default value
- https://github.com/damyon/moodle/compare/37c2490aa365c56b9b396fefe7c4b1f919ebf201...MDL-18014-master#diff-32edad94bae57ff6f456d9720ce62100R159 - why sync? This will slow down page submissions considerably for slow servers. This should be async with the session discarded immediately after validation server-side
- https://github.com/damyon/moodle/compare/37c2490aa365c56b9b396fefe7c4b1f919ebf201...MDL-18014-master#diff-32edad94bae57ff6f456d9720ce62100R181 (and in showMessage as a whole), I think we should use constants in the class rather than strings for info and warning
- https://github.com/damyon/moodle/compare/37c2490aa365c56b9b396fefe7c4b1f919ebf201...MDL-18014-master#diff-32edad94bae57ff6f456d9720ce62100R217 - missing the log source in this. There are others around which are also missing the log level
- https://github.com/damyon/moodle/compare/37c2490aa365c56b9b396fefe7c4b1f919ebf201...MDL-18014-master#diff-32edad94bae57ff6f456d9720ce62100R238 - perhaps move context above the event handler section to make it more visible?
- https://github.com/damyon/moodle/compare/37c2490aa365c56b9b396fefe7c4b1f919ebf201...MDL-18014-master#diff-32edad94bae57ff6f456d9720ce62100R221 - how does failure differ from the first section of success? Better to use a complete handler and one additional test perhaps?
- https://github.com/damyon/moodle/compare/37c2490aa365c56b9b396fefe7c4b1f919ebf201...MDL-18014-master#diff-c3cb144006c8f854e3a386af58cdc670R20 - why notify-base? Surely the submodule is notify?
- https://github.com/damyon/moodle/compare/37c2490aa365c56b9b396fefe7c4b1f919ebf201...MDL-18014-master#diff-c3cb144006c8f854e3a386af58cdc670R37 - shoudl by Overlay, not Y.Overlay for correct documentation generation
- https://github.com/damyon/moodle/compare/37c2490aa365c56b9b396fefe7c4b1f919ebf201...MDL-18014-master#diff-c3cb144006c8f854e3a386af58cdc670R69 - please don't use hyphens between the variable and description. No punctuation necessary
- https://github.com/damyon/moodle/compare/37c2490aa365c56b9b396fefe7c4b1f919ebf201...MDL-18014-master#diff-c3cb144006c8f854e3a386af58cdc670R75 - random whitespace
- https://github.com/damyon/moodle/compare/37c2490aa365c56b9b396fefe7c4b1f919ebf201...MDL-18014-master#diff-c3cb144006c8f854e3a386af58cdc670R37 - it's not actually an Overlay at all - it's a Node as defined on line 77
Andrew -
1. fixed
2. that sounds backwards to me - it's a function that does something not an attribute with side effects
3. because this is part of the form submission and the ajax request would be cancelled before it gets to the server
4. fixed - (this didn't work the first time I tried, but it's working now so whatever)
5. fixed
6. fixed
7. the differences are a) the server could not be contacted at all and the ajax request failed completely, b) the server was contacted, but there was an error response (session is no longer valid etc). I removed the duplication of the errorHandler.
8. changed
9. changed
10. changed
11. changed
12. changed
Re 2: I meant the path. It would give the possibility to specify an alternative URL in some situations.
I just had a demo from Damyon of the latest code. Only suggestion I could make was to shorten the notification string during a save to "Draft saved" so as to make it a little less distracting, but otherwise I agree it looks really slick now. +1
This is almost ready for integration - but not quite. There is still this outstanding:
"I think 6 is not right yet. E.g. grading students in mod assign does not distinguish between the students (so you could have text recovered for the wrong student). Same in forum - it doesn't distinguish the post/discussion."
Stick a fork in it - I'm calling this done.
The last change was to fix the "uniqueness" problem by using a hash of the current $PAGE->url.
The main moodle.git repository has just been updated with latest weekly modifications. You may wish to rebase your PULL branches to simplify history and avoid any possible merge conflicts. This would also make integrator's life easier next week.
TIA and ciao
Moving this issue to current integration cycle, will be reviewed soon. Thanks for the hard work!
Hi, this is definitely a great feature and all those nice popups look amazing.
But it really need to be reversible, so when the message "was automatically restored" appears, there should be a link "Cancel".
To prove you here is the interesting case:
- Create a label with an image, save it.
- Edit the label, add some text to it, wait 60 sec and close the window without saving
- Adjust the clock on the server (assuming it's your localhost) to be 5 days ahead, or wait for 5 days if you wish
- Run cron. This will delete draft file areas that are more than 4 days old
- Go to this label and start editing it - you won't see the images that existed there BEFORE your changes.
The problem here is that the files in filearea may be not images but linked files or videos and it won't be obvious that they are lost on re-editing. Saving such form will result in loosing content. It will be sensible to make lifespan of editor drafts less than lifespan of files draft area.
Hi Marina - I added 2 commits.
1 to force something into the undo stack when text is restored. This allows you to use the "undo" button to go back to the original text in the form.
2 to add a timemodified column to the drafts table, and never restore drafts older than 4 days. This is not a perfect sync with the draft file lifetime - but it's better than nothing.
Note this caused some unit test fails. There is a final commit on the branch to fix the failures. The failures were caused by the use of $PAGE->url which is a magic method that throws debugging if $PAGE->set_url has not been called.
I considered modifying lib/pagelib.php to not throw the debugging if we are in a unit test, but that seemed like a blanket fix and I can't say this warning will never catch something in a unit test (but then I can't think of how it would). Instead I called $PAGE->set_url in the failing tests.
Thanks Damyon, I think it is a reasonable fix for tests that analyze html generated on a page
Michael suggested this change: https://tracker.moodle.org/browse/MDL-46899
Removing qa_test_required label as I have made MDLQA-7152 ready for including in the next QA cycle. (Docs will be updated when we have 2.8 docs)
When I was playing with autosave today I had a thought about a an improvement to when we might make the saves - not sure if its a good idea or not, but created MDL-47822 to think about it.
Removed docs_required label as this is documented in https://docs.moodle.org/28/en/Text_editor#Autosave
I've added dev_docs_required to this issue as mentioned by Yuliya Bozhko - there does not seem to be any docs on how third party developers should handle how the autosave uniqueing etc works.
Removing dev_docs_required.


text:
Home Concert Tickets Rock and Pop Alanis Morissette
Alanis Morissette Tickets
Alanis Morissette has become one of the biggest female performers in the world over the last few years following the success of her breakthrough album 'Jagged Little Pill' in 1995. With the release of her latest record 'Flavors of Entanglement', Alanis Morissette tickets are going to be huge as she heads back on the road to wow audiences all over again with her brilliant back-catalogue including 'Hand In My Pocket', 'Ironic' and 'Thank U'.
Sign Up for Alanis Morissette Ticket Alerts
Sign up for the latest information on upcoming Alanis Morissette events. Be the first to know when Alanis Morissette tickets go on sale!
The email address you entered is invalid

subset: commoncrawl


text:
CASTLE DALE - Sally Ann Custer Cologie, age 67, passed away Aug. 10, 2012. Sally was born on Jan. 26, 1945 in Denison, Ohio to Albert and Betty Gibson Custer. She married Larry "Dago" Cologie in Hanover, Ohio on Feb. 14, 1964. Sally was raised in Scio, Ohio then moved to Castle Dale, UT in 1980. Family was the most important thing in Sally's life, and she especially enjoyed spending time with her grandchildren.
Sally is survived by her husband of 48 years, Larry; children: Lori (Arthur) McArthur of Huntington, Terri (Arthur) Bolotas of Billings, Mont. and Mike (Kollette) Cologie of Castle Dale; grandchildren: Dakota and Dallas McArthur, Rikko, Braydon, and Baylee Bolotas, Tyson (Emily) Huntington, Kade (Heather) Huntington, Jessica Huntington, and Brindy (Chris) Blake; and eight great-grandchildren. She was preceded in death by her parents.
As per Sally's request, there will be no public services. In lieu of flowers, please make donations to Community Nursing Services (480 South Carbon Ave., Price, UT 84501). Arrangements are in the care of Fausett Mortuary. Family and friends may sign the guest book and share memories of Sally at www.fausettmortuary.com.


text:
Levity Sibyl Wedge Pump
Sorry, this item is sold out!
Looks like you've got more shoe shopping to do - have fun!
Looks like you've got more shoe shopping to do - have fun!
Item # 236912
Complete your look in the Sibyl by Levity. This wedge pump is perfectly paired with your skinny trousers for a chic look that's right on trend.
- Suede upper
- Ankle strap with a back zipper closure
- Peep toe
- 1½" platform, 4½" braided wedge heel
- Synthetic sole
- Imported
By: Laon
Location: Georgia
February 20, 2013
"like color contrast between the wedge and the upper part of the shoe. (i bought the cognac color) i also like the that ankle strap isn't tight enabling you to walk without it rubbing against ankle. the platform also helps the shoe more stable and easier to walk in."
By: MissMeg
Location: RC, Ca
December 30, 2012
love this wedge
"runs true to size, very comfortable. looks great with jeans rolled up, looks great with summer skirt. definitely recommend!"
By: SiSii
Location: Pembroke Pines, FL
December 22, 2012
Love the height
"wore these shoes around the house all day that I received them. I could not take it off ."
By: believesan9394
Location: California
August 15, 2012
very nice and comfortable heels
"I did not expect these pair of heels are so comfy."
Click anywhere to close this.


text:
Tasty and the price is right
Verified Purchase
Tasty and the price is right
Best tasting Sunflower Oil on the market. There is no other raw sunflower oil product on the market for cheaper than this. Buy Flora.
Tasty and the price is right
Best tasting Sunflower Oil on the market. There is no other raw sunflower oil product on the market for cheaper than this. Buy Flora.
Flora - Orgaic Sunflower Oil,
Posted by Reviewer2857415 on Aug 17, 2011
This oil has delicious mild taste and it is perfect in salads, hot cerials, and many other dishes. We like it much better then the olive oil.
Great for "oil pulling"
Posted by Reviewer2764007 on May 17, 2008
I use this oil for "Oil Pulling" taste like sunflower seeds. Great quality oil.
So far so good.
Posted by Reviewer1656749 on Aug 20, 2008
I use it in a different form than most people. I gargle it, yes I gargle it on an empty stomach 1st thing in the morning for 10 - 15 min. The trick is to get it to turn into a white color. Apparently, it helps detox the body, and it helps with a variety of issues. Including tooth and gum disease. I was having a problem with one of my tooth and it is getting better already. I have only been using it for 2 - 3 weeks. I've heard that you can see tremendous results after a couple of months. So we'll see! :)
Flora, Sunflower Oil, 17 fl oz (500 ml
Posted by Reviewer1222770 on Jan 10, 2009
The product is very pure and so great for the skin. Thank you.
Great Stuff
Posted by Reviewer2348333 on Sep 08, 2009
An affordable, ultra high quality sunflower oil. Organic, cold pressed, fresh and in dark bottles. I make up a mix of 3 parts sunflower oil, to 1 part flax oil and then I have an amazing Body Bio equivalent oil with an Omega 6 to Omega 3 ration of 4:1. This is the ratio that is used by Dr Patricia Kane - queen of oils! And I will say that it reduced the rate of my seizures by about 70% - which wa pretty amazing since I had already been taking lots of "good" fats in the from of fish oils etc. But Dr Kane has done her research and shown that whilst we do need some fish oils, taking to many, hugely over balances the body and we need lots of the omega 6 too. Hence this wonderful sunflower oil. Studies have show this ratio to reduce seizures, irritability, inflammation and more. Good luck
Great buy!
Posted by Reviewer2427967 on Nov 03, 2009
Great product, especially mixed with safflower oil.Great for skin and hair. Will purchase again!
Flora Sunflower Oil
Posted by Reviewer1373824 on Mar 31, 2011
Good taste, and love that it comes in an amber GLASS bottle
Posted by Reviewer2831712 on Apr 05, 2011
This product is excellent. Please continue to offer it!
Love this product!
Posted by Reviewer1098759 on Apr 15, 2011
I love Flora. I've been buying from them since 1995 when I discovered Udo's Choice 3-6-9 oil. I use most of their oils because of how they process them. I'm willing to pay the price for organic, unrancid oils. I buy in quantity and store them in the freezer until needed. Fabulous source of healthy Omega 6s.


text:
Marie Millet, College de France, Paris
I've recently spent two weeks working at the British Museum, meeting colleagues working on the Amara West project, drawing pottery from last season's excavations and also looking at archive material. Though the majority of our finds, including pottery, stay in Sudan, each season we have the opportunity to bring back samples for scientific analysis, and also to borrow vessels of particular interest for conservation and reconstruction. These will be returned to Sudan in due course.
I have previously written about the shapes and purposes of the vessels we find in excavations, but another important part of working on pottery is to study the fabrics, that is, the different preparations of clay – often mixed with materials such as chaff – used to make the vessels. As the composition of clay varies from region to region, the fabrics can indicate where a vessel may have been made, which has implications for the organisation of production, transport and trade networks. I completed an initial classification on site using a hand-lense that provides magnification of 20x.
Back in the British Museum laboratories, a range of scientific techniques can be applied to refine my classification, using much higher magnifications, but also analysis of the inclusions and chemical make-up of individual samples. This research is being led by Michela Spataro of the Department of Conservation and Scientific Research. Preliminary results suggest that much of the 'Egyptian-style' pottery which dominates the assemblage at Amara West is actually being produced in the local region, from clay very similar to that used for the Nubian handmade cooking vessels. Yet we have no evidence for the kilns in which this pottery was made.
Conservator Rachel Swift carefully reconstructed fragments of Mycenaean stirrup jars, found in a domestic context in the southwestern corner of the town. These distinctive vessels were used to store oil or perfume, and can provide insights into the inhabitants' access and desire for imported luxury products. Rachel's work produced fragments of four different vessels, and Andrew Shapland, curator in the Department of Greece and Rome, brought us to a storeroom where a large collection of similar vessels from other excavations are housed. This provided us with a better sense of the date of these vessels, but also illustrated how much the decoration and pottery fabric itself could vary. Such variations can hint at whether the vessels were produced in Greece, or were imitations produced in the Levant or Egypt. We now plan chemical analyses to confirm where each vessel was made.
Filed under: Amara West, Archaeology


text:
- Sign in
- Join
- Find a rental
- Traveler Inbox
- Rental types
- Newest Wellfleet Rentals
- 3 Bedroom Wellfleet Rentals
- 4 Bedroom Wellfleet Rentals
- Kid Friendly Wellfleet Rentals
- Pet Friendly Wellfleet Rentals
- Last Minute Wellfleet Rentals
- 2 Bedroom Wellfleet Rentals
- Waterfront Wellfleet Rentals
- Cheap Vacation Rentals in Wellfleet
- Wellfleet Beach Rentals
- 5-Star Wellfleet Rentals
- See more rentals
- How to book
- Traveler Help Center
- Write a review
Description from the manager
Description from the manager
Bedrooms: 3/
Bathrooms: 3/
Sleeps: 6/
Type: House
Book this 3 bedroom, 3 bathroom house in Wellfleet today! A total of 6 people can sleep here comfortably.
Guests can enjoy a deck, outdoor grill, and parking space among other amenities offered by this rental.
No travelers have shared a review of this property yet.
Costs vary, with the average weekly rate as low as $2,500.00 to as high as $4,000.00, depending on travel dates.
The owner last updated the property's calendar today.
About the manager
About the manager
William Raveis - The Rental Company
William Raveis - The Rental Company
- Response rate: n/a
- Response time: n/a
- Calendar updated: today
Overall rating:
4.5 / 5.0
More properties Call: +1-800-997-0317
Proximity to TripAdvisor's Top Wellfleet Attractions
Proximity to TripAdvisor's Top Wellfleet Attractions
Reviews (0)
Also consider
- FlipKey has rentals in over 11,000 destinations around the world:
- Hawaii vacation rentals- 7,867 rentals from $100/night
- Harbor Island vacation rentals- 439 rentals from $119/night
- Brigantine vacation rentals- 145 rentals from $121/night
- Stuart vacation rentals- 110 rentals from $79/night
- Carova Beach vacation rentals- 304 rentals from $174/night


text:
What programs do you immediately think of when you think of a skater? I'm still working on putting my skating tapes to DVD, and I tripped upon one of the many versions of Brian Orser's "Story of my Life" - which I think is unarguably his 'signature' piece or at least his signature song.
let's post some videos from memory lane this off season, shall we?


text:
Texas Tackle Split Ring Pliers
If you've torn your thumbnail or cut yourself with your knife trying to pry open a stubborn split ring, then you'll really appreciate these great split ring pliers from Texas Tackle. Texas Tackle used top grade surgical stainless steel for precision and durability, and they completely covered the handles with a slip-resistant, textured plastic grip to ensure maximum control - even when your hands are wet.
Best of all, a spring automatically opens the pliers, so all it takes is one hand on the lure and one hand on the tool to easily remove any split ring. The handy 5-inch size will fit in any tackle box. Called "the world's best split ring pliers" by Saltwater Sportsman Magazine - the Texas Tackle Split Ring Pliers. Get a pair today.
Length: 5"
More From Texas Tackle Pliers
Customer Reviews
Comments: Highly disappointed given the amount of glowing reviews here which by the way I read before placing my order. So, what's the problem with it? Simply put, the pointed bit of the pliers used for prying open the split ring is just not sharp nor long enough. It was HARD work to get anything open. I only received it today and I am already looking around to buy another pair cos is that bad.
From: Alex: USA 8/11/16
Comments: These are the last pliers you'll ever need for any size split rings you'd use for bass fishing. I've opened some really small ones using them, no problem. Very well made and well worth it.
From: Tony: Yukon, OK 7/9/16
Comments: Hands down the best split ring pliers I've ever owned. Easy to use, compact & great quality. These don't disappoint.
From: Andy: West End, NC 4/2/15
Comments: Best split ring pliers I have used. I keep one in the boat and another in the man cave.
From: Neil: Amarillo,TX
Comments: This plier is astonishing. It's cheap, well made, and does it's job perfectly. If you're like me who swap all the trebles on crankbaits, do your self a favor and BUY IT NOW!! You will not regret it!!!
From: Toshiya: IL
Comments: I've used these for a few years in the midwest & no downside to them. I change out nearly all of my trebles & the function & durability of this tool is flawless. I didn't check to see what part of the country the guy was in that mentioned rust, but mine are kept in my boat in the garage, & haven't shown the slightest hint of rust. You won't be able to spend more, or less, & have a better tool for this application - IMHO. They work better than any other split ring pliers I've ever used & I've turned several friends onto them that agree...
From: Mark: Gardner, KS
Comments: Have owned a pair of these for over 10 years. For the hard bait fisherman that changes out the stock hooks,best investment you will ever make.These are the best made split ring pliers out there. On the comment about them rusting up, how does stanless steel rust?
From: Ronnie: Lake Fork, TX
Comments: These are great pliers, just started changing out my hooks and stuff and thought i was gonna have trouble at first but after like 10 minutes i was changing on and off hooks in like 10 seconds, these work great!
From: Matt: IL
Comments: These are "ok" for a while till they rust up on ya in a short time,save your money guys and look at something else.
From: BK: Ohio
Comments: This is a winner .I have tried other snap ring pliers, these are the only ones you will need.Buy them ,you won't be disappointed.
From: Keith: Madison, GA
Comments: These are the deal. Don't even think that there is another pair that is better. They are awesome. Have made the mistake of buy Rapala a few times thinking that they will somehow work, not the case. These are so very simple to use, well made and with the orange handle easy to find. Worth every penny.
From: Rick: Oak Park, IL
Comments: These things are fabulous. My friend, who uses split rings a lot in her jewelry, told me her 4th pair of split ring pliers had just lost the tip (didnÕt even have them a month). I remembered reading something about a pair of pliers made for the fishing industry ‹ and finally found them. Bought a pair for my friend, and one for me. My friend just absolutely loves hers. She said that she canÕt believe how much time she had wasted trying to get the rings opened before.
From: Bobbie: Miami, FL
Comments: Make in Pakistan but very sturdy and and they work great. The spring between the handles defaults the jaws in the open position so they are easy to use, even on size 0 split rings. The lower jaw extends beyond the upper jaw which is the key to the design. No "pinching" the split ring and popping it on the floor. 2 thumbs up.
From: Rick: Orrville, OH
Comments:Best split ring pliers on the market. Simple to use.
From:Bill: Port Vue, PA


text:
The Summer of Chevy: Is it just Dudley-Do-Wrong?
Kevin McCartney
July 31 2013 04:55PM
Coming into the summer, it was plain to see that it would be a defining one for the future of the franchise and for the legacy of General Manager Kevin Cheveldayoff. Ten picks at the draft for a prospect starved franchise, just 19 contracts signed to the 50 man limit for a chance to re-shape the team, and the first set of season ticket commitments expiring at the end of the 2013-2014 season was the backdrop to the 'Summer of Chevy.' With 23 men on the NHL roster and just over $2M left in cap space, it would appear that the Summer of Chevy is nearly complete.
Our friend Ryan Blight over at Arctice Ice recently wrote a column that is quickly shaping how we talk about this summer in Jets Nation. He contends that by locking up the same core of players put together by Rick Dudley in Atlanta's final year, Cheveldayoff has ensured the squad remains the "woeful Atlanta Thrashers."
The reality is slightly more worrisome for the Jets and their fans. With the evidence of three off-seasons and two years of Jets hockey, I think we can start to fret that Cheveldayoff is a 'low-reward' style manager.
Japanese Cars Are Better
In his three off-seasons as GM, Chevy has very much set himself apart from Rick Dudley. Dudley, in his first and only season as GM, made dramatic changes to the lineup, including adding Byfuglien, Ladd, Wheeler, Stuart, and Sopel. We've seen enough of Chevy to generously qualify him as a conservative manager. Let's review briefly.
He is maligned for his use of the Waiver Wire, which he has used 8 times in 2 seasons to pluck Brett MacLean, Ben Maxwell, Antti Miettinen, Grant Clitsome, Anthony Peluso, James Wright, and Mike Santorelli from other (mostly terrible) teams. He signed Wellwood in year one, who then went on to a remarkable 47 point season, was re-signed for another year and then allowed to walk this off-season. During last summer, he signed Jokinen and Ponikarovsky, and then traded Oduya and Poni for draft picks early-ish in the year while letting Jokinen play out a miserable, pointless season of hockey. He declined to trade Ron Hainsey at this year's deadline in spite of his upcoming UFA status and the (now obvious) intention of the team to let him walk. Yet, he also declined to trade for any help for his playoff-bubble team who fell just short of the franchise's second ever playoff appearance as injuries took their toll during the stretch run. Worst, he has stood behind Head Scout Marcel Comeau, despite his atrocious draft record and key role in making the perpetually re-building Atlanta Thrashers really, really bad.
It's not the resume of a world-beater.
The true problem is that his moves aren't conservative as in low-risk, they're conservative as in low-reward. If we consider risk and reward in the matter of wins, waiver wire players are almost always high-risk (losses), low-reward (wins) when added to be prominent members of an NHL roster (the case for 4ish of the 8 above). If we consider risk and reward from the standpoint of cap management, this summer has been one of high-risk, low-reward gambles also, and the 'Big 3' RFA contracts are a perfect example.
High-Risk, Low-Reward sounds backward...
As Ryan Lambert wrote on Puck Daddy after the Wheeler contract, giving 6 years to a 27 year old is a form of risk (somewhat high risk in Lambert's opinion). The likelihood that Wheeler is as good at 33 is low, creating inefficiency in the team's budget. In this particular case, I think Wheeler's spotless injury record through 5 years of NHL play after turning pro at an unusually old 22 gives him a better shot than most at being productive post-30, but there is no denying that it would be almost impossible for Wheeler to out-perform his $33.6M contract. We can simply speculate as to whether he will under-perform during its duration.
I came to the same conclusion writing about the Bogosian contract. It is an outrageously risky deal at 7 years in length for a 23 year old who can boast just 98 games of Top-4 quality hockey (and 200 games somewhere below that quality) and a long injury history. Cheveldayoff avoided a high-reward risk back in September 2011 when he signed a struggling Bogosian to a short term deal, and now he's made a low-reward risk in signing him to a massive contract we can only hope he performs up to.
Little? He probably has the best chance of not being an anchor at the end of his shorter 5 year contract, but he'll be hard pressed to out-perform his $4.7M a season either.
The same was true of his last round of huge contracts. Enstrom, Ladd, Kane, and Pavelec all got long-term, big money deals. Ladd was legitimately better than his $4.4M cap hit this past year but fans wait with baited breathe for the redux, while Kane is still growing into his $5.25M paycheque, Enstrom struggled enough this year to cast some doubt on the new deal that starts in October, and Pavelec is plain awful. But you know what's easier than telling your boss you need millions of dollars to buy out your mistake? Taking the very high-risk, very low-reward chance that Pavelec will improve and grow to earn his millions.
We can say that all of these deals are fair - and they are. The players got what the market would bear, and no one can doubt that all apart from Pav, these players are valuable additions to any NHL team. At the same time, they represent an approach by Cheveldayoff that appears constant and simply doesn't work to build a winner. He's taking risks, but the risks have little or no reward attached to them. The outcomes are either bad or not bad - the players either underperform their contracts, or perform up to their contracts.
In the moment of signing, there is no hope (outside the kind of hope we all have when checking our lotto numbers) for these players to out-perform over the life of the contract. Worse, we can't even say he's making a 'win-now' trade off. Long term deals are used precisely to lower the cap value so that (for at least part of the deal) the team is getting more than what they paid for while the player gets job security when the opposite is true. In Chevy's case, the players are simply being given term to reflect the team's impression of the player in that moment.
What about Setoguchi and Frolik?
I'm not sure there is a lower-reward top 6 winger in the league than Setoguchi. The risk is that he's not good enough to score without Thorton and Heatley (when he was good) quality teammates. The reward is that he can score 40 points again. As for Frolik, it was a shrewd move that cost very little and has little risk. Well done, Cheveldayoff. He'll look great with Burmistrov... oh, yeah.
Why is he GM?
I can't believe the narrative that he's just worse at his job than I would be, or even than Ryan Blight would be (sorry, Ryan - still friendsies??). His work with the Chicago Wolves shows he knows a good hockey player from a bad one, and can assemble a team under a budget. Granted, I'm super awesome at Be a GM mode, but something tells me his job is harder than EA Sports makes it seem. (Seriously, you can just trade your 1st round pick 5 years in the future for the 1st overall pick like every season...)
What I can believe is that he's worse at his job than many of the other NHL General Managers, who are all trying to get better every year. Worse, I can believe that he doesn't have a planned window of opportunity. The team doesn't appear to be building toward a particular period of time in which its players are on value deals or there is cap room to shoe-horn in more talent for a playoff run.
So long as he's not wasting money, creating bad press, or polarizing the board room, I suspect he has fairly long term employment. We can look forward to another 8 waiver picks ups, watching Jokinen walk for nothing, and listening to the team talk about building from within while avoiding accountability in any form.
But at least he's not Rick Dudley!
We will remain friendsies... but just... =D
Appreciate the link. And yes, I'm on board with much of this piece as I am not a fan of Chevy's body of work.
My issue remains the fact that year one was a wasted "evaluation year" that Rick Dudley wouldn't have needed. In fact, I'm not sure why we needed it anyway with Marcel Comeau coming up anyways.
But hey, we could have Dave Nonis or Jay Feaster in town so at least we've got that going for us!
August 01 2013, 09:04AM
I was in a good mood until I read your blurb Kevin. What a Debbie downer that was!
Look on the bright side...a recent photo of Dustin Buff appeared to have him looking somewhat slim and trim.
Big year for Buff!
So you're complaining that he hasn't traded away any good players or high draft picks??
It's clear the org missed on Pavelec and Jokinen, though I think Jokinen was a good bet. Losing Burmi obviously hurts but it's hard to know exactly why that decision made.
I like the waiver wire action because it tells me the org is not satisfied with the fringes of the roster. Still not sure about the logic of waiver wire player being high risk low reward. The only resources going to acquire the player are $$ and roster spot while if then don't pan you send them down the road, low risk (and low reward) but at least there is competition.
The reality is that only one team gets to win it every year and that this organization appears to be building to be consistently good without blowing it's wad. Much better than trading prospects for fading Keith Tkachucks and Zhitniks.
August 01 2013, 05:26PM
Ill trade you guys for Kevin Lowe.
I have a hard time seeing better options out there for the Jets. There is not a line up of top tier players waiting to sign in Winnipeg. If nothing else, these signings show this is an organization players are willing to commit to and a city they want to play in.
I also don't understand this love affair with Burmistrov. The guy had 3 seasons to show his skills and couldn't even manage 30 points. Does this team need a 175 pound third line centre who doesn't play physical?


text:
What with black holes, dark energy, and so on, it's a big strange universe out there. Science fiction films add more strangeness when they include weird and wonderful aliens. The closest we've come to real aliens so far is evidence of water that could support life, past or present, at a few sites in our solar system. But we have recently found lots of extrasolar planets and that helps fuel a long tradition of speculating about life in the universe.
Moon creatures appeared in the first science fiction flick ever, the French Voyage dans la Lune (Voyage to the Moon, 1902). In 1924, the Soviet film Aelita: Queen of Marsshowed an intricate Martian society. Since the 1950s, other new and improved models of aliens have appeared in films – literally improved, since the steady development of special effects, especially computer generated imagery, has made even extremely strange aliens look believable on screen.
Plenty has been written about what our fascination with aliens says about ourselves. Some aliens are human-seeming (like the alien emissary in the 1951 and 2008 versions of The Day the Earth Stood Still) but they're mostly an unsettling lot, which may reflect human paranoia. It's hard to warm up to the slavering reptilian predator of Alien (1979), the insectoid creatures of Starship Troopers (1997), or the monkey-like bestial aliens of War of the Worlds (2005). With their hostility to humanity, these ugly customers return our repulsion in spades. That's not to ignore the few appealing aliens that have appeared on screen. Movie viewers found the lost alien in E. T. (1982) endearing despite his funny looks, and the Disney-like Ewoks in Star Wars Episode VI: Return of the Jedi (1983) are cute and fuzzy.
Things get more interesting though when we're asked neither to exclaim "how cute!" or to blow away an alien, but to actually relate to one, as in the just released film District 9. The film imagines a world in which over a million alien beings have been sequestered for years in District 9 outside Johannesburg, South Africa. This has plenty of parallels with South Africa's racial history, complete with shanty towns, gang warfare, and military, legal, and quasi-legal maneuvering to control the aliens.
But these tall insect-like bipeds with tentacles around their mouths aren't just a little bit different; they're truly inhuman and truly unappealing. Yet they have intelligence, parental feelings, a sense of justice and of loyalty, and a desire to leave their squalid conditions and return home. We discover this as the human in charge of resettling District 9 finds himself more connected to the aliens than he ever wanted to be. He works together with one of them for common goals, and though they don't exactly become friends, they bond.
This can be read as a parable about black-white interaction or more broadly about how to accept what is unfamiliar to us. Either way, the "alien other" carries messages we need to hear. That's one reason why I hope that if and when we find alien life, it will be more advanced than a smear of lichen on a Martian rock.
BTW, in my previous post about the Mexican science fiction film Sleep Dealer, I commented that Hollywood science fiction always has the aliens land in New York or Washington, DC, whereas Sleep Dealer brings a different third world perspective. Similarly, the characters in District 9 are surprised to see a spacecraft hovering over Johannesburg rather than NY or DC, and this film likewise enriches the story with its own particular South African background. Both films are examples of what I hope is a growing global approach to science fiction.
For more about Sidney Perkowitz and science in film, visit http://www.sidneyperkowitz.net/


text:
ELMO-Velma Allred age 77, passed away Dec. 31, 2009 in Elmo, Utah. She was born to Adelbert Lee and Annie Irene Axelsen Childs on March 25, 1932 in Elmo, Utah. Velma was married to Roy E. Johansen for more than 25 years. She was also married to Parlan Ray Allred for more than 20 years.
Velma had many hobbies and interests including; cooking, sewing, making quilts, gardening, baking bread, watching the Jazz games with her friend Nina, being in the desert and mountains picking rocks and especially her hollyhocks. She made many quilts for her family and friends, once she started counting it totaled 1,151.
Our beloved mother, grandmother, sister and friend. "We will miss you, but your quilts will keep us warm and the recipes you taught us will be handed down. We will forever treasure your friendship. We are grateful for your love and your life. Velma's greatest joy was her children and grandchildren; K.C., Jessica, Shaney, Tandie, Jake, Lacey, Dane, Jay, Ashley, Kade, Braxton, Jacie, Colton, Eric, Michelle and Timothy, great-grandchildren; Gavin, Kaydynce, Chad, Anndie, Beritt, Wiley, Haiden, Jaxsten, ShiAnne, Aundrea, Gage, Kane and Chloe.
She is survived by her children; Chris Johansen, Nita (Marvin) Thayn, Tina (Vern) Lyons, and Jenni (Bill) Fasselin all of Elmo, Utah, and David Allred of Oklahoma 16 grandchildren, 13 great-grandchildren, siblings; Leora Johansen of Price, Ann Fivecoat of Elmo and Darlene (DaVoy) Acerson of Riverton, Utah.
She is preceded in death by her parents, husbands, son; Jeff Johansen, sister; Shirley Brown, brothers; Sheldon Childs and Ken Childs, and daughters-in-law; Susie Johansen and Debbie Allred.
A memorial service will be held on Saturday, Jan. 9, 2010 at 11 a.m. at the Elmo Town Hall. Graveside services will follow at 12 noon at the Elmo Town Cemetery. Services are in the care of Fausett Mortuary. Friends and family may sign the guestbook and share memories of Velma at www.fausettmortuary.com