<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		xmlns:itunes="http://www.itunes.com/dtds/podcast-1.0.dtd"
	xmlns:media="http://search.yahoo.com/mrss/"
	>
<channel>
	<title>Comments for Engage Blog</title>
	<atom:link href="http://blogs.talis.com/engage/comments/feed/" rel="self" type="application/rss+xml" />
	<link>http://blogs.talis.com/engage</link>
	<description>Blog for the Engage project</description>
	<lastBuildDate>Wed, 06 Apr 2011 09:49:26 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.1</generator>
	<item>
		<title>Comment on Redesigning the Calendar by Andrew Cothliff</title>
		<link>http://blogs.talis.com/engage/2011/02/25/redesigning-the-calendar/comment-page-1/#comment-123</link>
		<dc:creator>Andrew Cothliff</dc:creator>
		<pubDate>Wed, 06 Apr 2011 09:49:26 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.talis.com/engage/?p=731#comment-123</guid>
		<description>I definitely think that option 3 is the &#039;best fit&#039; as I think 4 will face the same drawbacks as option 1 in that the shear volume of events would mean an awful lot of scrolling for the user.  I would also suggest that there should be a simple way of filtering by location.
I like the clear interface in option 3 which is very intuitive for the user.</description>
		<content:encoded><![CDATA[<p>I definitely think that option 3 is the &#8216;best fit&#8217; as I think 4 will face the same drawbacks as option 1 in that the shear volume of events would mean an awful lot of scrolling for the user.  I would also suggest that there should be a simple way of filtering by location.<br />
I like the clear interface in option 3 which is very intuitive for the user.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Redesigning the Calendar by Heather Spencer</title>
		<link>http://blogs.talis.com/engage/2011/02/25/redesigning-the-calendar/comment-page-1/#comment-122</link>
		<dc:creator>Heather Spencer</dc:creator>
		<pubDate>Thu, 10 Mar 2011 16:30:52 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.talis.com/engage/?p=731#comment-122</guid>
		<description>Some thought has obviously gone into this. Interesting that you use Lancs&#039; calendar for your examples!
I too like 3 &amp; 4. I like the look of 3 as it&#039;s clear and gives you the option to pick a date too. 4 is good as it may be helpful to see a week at a time for events with a few days&#039; run, such as theatre. It&#039;s a neat feature having it pre-loaded to slide in from the side.
Like Glyn, I wondered how you envisaged using an empty day for forthcoming events – it could be useful or it could be really confusing! Some order to the events is also necessary - start time would be logical.
There still need to be facets on the calendar, specifically event type and location/area, but possibly also cost, ie. free or not. This is pretty standard functionality on other event-listing websites, and with a county the size of ours it&#039;s necessary to avoid losing customers who think it&#039;s all too much to trawl through.</description>
		<content:encoded><![CDATA[<p>Some thought has obviously gone into this. Interesting that you use Lancs&#8217; calendar for your examples!<br />
I too like 3 &amp; 4. I like the look of 3 as it&#8217;s clear and gives you the option to pick a date too. 4 is good as it may be helpful to see a week at a time for events with a few days&#8217; run, such as theatre. It&#8217;s a neat feature having it pre-loaded to slide in from the side.<br />
Like Glyn, I wondered how you envisaged using an empty day for forthcoming events – it could be useful or it could be really confusing! Some order to the events is also necessary &#8211; start time would be logical.<br />
There still need to be facets on the calendar, specifically event type and location/area, but possibly also cost, ie. free or not. This is pretty standard functionality on other event-listing websites, and with a county the size of ours it&#8217;s necessary to avoid losing customers who think it&#8217;s all too much to trawl through.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Redesigning the Calendar by Matt Machell</title>
		<link>http://blogs.talis.com/engage/2011/02/25/redesigning-the-calendar/comment-page-1/#comment-110</link>
		<dc:creator>Matt Machell</dc:creator>
		<pubDate>Mon, 07 Mar 2011 11:25:11 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.talis.com/engage/?p=731#comment-110</guid>
		<description>Hi Glyn,

The hover approach would be fully accessible due to keyboard-only and non-javascript fallbacks. However it would result in an initially contracted view,  this is the big disadvantage with calendar views, unless they show everything like version 1. 

For the forthcoming events in option 3, the concept would be that if a particular day was empty, we could show a link to the next day with events in addition to the next/previous day buttons. The possibility exists of also showing an example of the events from a later day, but that has the potential to confuse unless really clearly de-limited. 


Keith,

thanks for stressing the importance of thematic groups of events in the calendar;  I do wonder if for a day view expected behaviour for end-users would be start-time order. We could flag each event&#039;s tags in the display of version 3 to provide scan-ability by theme.</description>
		<content:encoded><![CDATA[<p>Hi Glyn,</p>
<p>The hover approach would be fully accessible due to keyboard-only and non-javascript fallbacks. However it would result in an initially contracted view,  this is the big disadvantage with calendar views, unless they show everything like version 1. </p>
<p>For the forthcoming events in option 3, the concept would be that if a particular day was empty, we could show a link to the next day with events in addition to the next/previous day buttons. The possibility exists of also showing an example of the events from a later day, but that has the potential to confuse unless really clearly de-limited. </p>
<p>Keith,</p>
<p>thanks for stressing the importance of thematic groups of events in the calendar;  I do wonder if for a day view expected behaviour for end-users would be start-time order. We could flag each event&#8217;s tags in the display of version 3 to provide scan-ability by theme.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Redesigning the Calendar by Keith Burrows</title>
		<link>http://blogs.talis.com/engage/2011/02/25/redesigning-the-calendar/comment-page-1/#comment-107</link>
		<dc:creator>Keith Burrows</dc:creator>
		<pubDate>Mon, 07 Mar 2011 09:23:26 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.talis.com/engage/?p=731#comment-107</guid>
		<description>I definitely do not like Option 2 – there is too little available on the initial screen without further clicking. I agree with my colleague Gill that options 3 or 4 are preferable, although I personally prefer option 3.
Although it has the disadvantage of only showing a day at a time rather than a week it has the clear advantage of showing occurring events in more detail on the front page. The mini-calendar layout does make it very easy to select a day, and it is my experience that people generally have free days rather than whole free weeks and will be looking for something to do in their locality on that particular day(s) of the week they are free.
I know other of my colleagues have also discussed and commented and I would like to reinforce one particular comment that the listing for options 3 or 4 would be better in a thematic order if possible, and I would suggest by area for the reason outlined in the previous paragraph.</description>
		<content:encoded><![CDATA[<p>I definitely do not like Option 2 – there is too little available on the initial screen without further clicking. I agree with my colleague Gill that options 3 or 4 are preferable, although I personally prefer option 3.<br />
Although it has the disadvantage of only showing a day at a time rather than a week it has the clear advantage of showing occurring events in more detail on the front page. The mini-calendar layout does make it very easy to select a day, and it is my experience that people generally have free days rather than whole free weeks and will be looking for something to do in their locality on that particular day(s) of the week they are free.<br />
I know other of my colleagues have also discussed and commented and I would like to reinforce one particular comment that the listing for options 3 or 4 would be better in a thematic order if possible, and I would suggest by area for the reason outlined in the previous paragraph.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Redesigning the Calendar by Glyn Sinar</title>
		<link>http://blogs.talis.com/engage/2011/02/25/redesigning-the-calendar/comment-page-1/#comment-104</link>
		<dc:creator>Glyn Sinar</dc:creator>
		<pubDate>Sat, 05 Mar 2011 10:33:14 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.talis.com/engage/?p=731#comment-104</guid>
		<description>Of all the options I think 3 is best, although 1 has merits and I agree with Gill and Carolyn that 4 is also a strong contender to 3.  In Lancashire we do still need facetting on the calendar because of the huge geographical spread - dealing with &#039;local events&#039;!
The &#039;expand on hover&#039; approach in 2 can be confusing for some users and I&#039;m not sure how DDA compliance this would be.  All events seem concatenated in this view as well, not easy to pick out.  The diary view in 3 is much clearer but 4 is much more like what Outlook users etc are familiar with and the pre-loading of information could present a quicker and smoother tool.  Speed of page loading is crucial.
I&#039;m interested in hearing more from you on how with 3 an empty day could provide opportunities to display forthcoming events - how and where would that happen?
Finally - whichever path is adopted, could there be some sort order for the display of events for each day?  In the examples - notably the diary view, we appear to have some alphabetical order but then it starts again as a double sequence.</description>
		<content:encoded><![CDATA[<p>Of all the options I think 3 is best, although 1 has merits and I agree with Gill and Carolyn that 4 is also a strong contender to 3.  In Lancashire we do still need facetting on the calendar because of the huge geographical spread &#8211; dealing with &#8216;local events&#8217;!<br />
The &#8216;expand on hover&#8217; approach in 2 can be confusing for some users and I&#8217;m not sure how DDA compliance this would be.  All events seem concatenated in this view as well, not easy to pick out.  The diary view in 3 is much clearer but 4 is much more like what Outlook users etc are familiar with and the pre-loading of information could present a quicker and smoother tool.  Speed of page loading is crucial.<br />
I&#8217;m interested in hearing more from you on how with 3 an empty day could provide opportunities to display forthcoming events &#8211; how and where would that happen?<br />
Finally &#8211; whichever path is adopted, could there be some sort order for the display of events for each day?  In the examples &#8211; notably the diary view, we appear to have some alphabetical order but then it starts again as a double sequence.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Redesigning the Calendar by Matt Machell</title>
		<link>http://blogs.talis.com/engage/2011/02/25/redesigning-the-calendar/comment-page-1/#comment-98</link>
		<dc:creator>Matt Machell</dc:creator>
		<pubDate>Fri, 04 Mar 2011 15:07:00 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.talis.com/engage/?p=731#comment-98</guid>
		<description>Hi Gill,

yes, that&#039;s our primary concern too, in that a high volume of events need to be presented in a digestable form. The biggest issue is retaining the &quot;at a glance&quot; nature of a month-calendar in the alternate designs.

Regarding option 4, yes event titles are links through to the relevant event. The main difference is the week-level focus and the fact that for browsing the calendar you don&#039;t need to refresh the page.</description>
		<content:encoded><![CDATA[<p>Hi Gill,</p>
<p>yes, that&#8217;s our primary concern too, in that a high volume of events need to be presented in a digestable form. The biggest issue is retaining the &#8220;at a glance&#8221; nature of a month-calendar in the alternate designs.</p>
<p>Regarding option 4, yes event titles are links through to the relevant event. The main difference is the week-level focus and the fact that for browsing the calendar you don&#8217;t need to refresh the page.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Redesigning the Calendar by Gill Irvine</title>
		<link>http://blogs.talis.com/engage/2011/02/25/redesigning-the-calendar/comment-page-1/#comment-95</link>
		<dc:creator>Gill Irvine</dc:creator>
		<pubDate>Wed, 02 Mar 2011 19:36:07 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.talis.com/engage/?p=731#comment-95</guid>
		<description>Out of the options above I would suggest either 3 or 4. 

My concern would be that if the calendar is overloaded with a lot of information people will find it difficult to navigate and browse. I take it in option 4, each item is a hyperlink which opens up more information when clicked on?If this is the case option 4 may the better of the two preferred options.

Thanks</description>
		<content:encoded><![CDATA[<p>Out of the options above I would suggest either 3 or 4. </p>
<p>My concern would be that if the calendar is overloaded with a lot of information people will find it difficult to navigate and browse. I take it in option 4, each item is a hyperlink which opens up more information when clicked on?If this is the case option 4 may the better of the two preferred options.</p>
<p>Thanks</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Talis Engage release to preview 3rd November 2010 by Lucy Conder</title>
		<link>http://blogs.talis.com/engage/2010/11/03/talis-engage-release-to-preview-3rd-november-2010/comment-page-1/#comment-92</link>
		<dc:creator>Lucy Conder</dc:creator>
		<pubDate>Thu, 04 Nov 2010 16:09:56 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.talis.com/engage/?p=617#comment-92</guid>
		<description>Hi, thanks for your work on pending suggestions and links to subjects - here is my immediate response. Looking forward to seeing the release here.

Response to 3rd November release preview

1	Pending suggestions for alteration

This worked well in the test site but we wonder if the Record History will show where the amendment came from. In the existing system we have to add a 2nd note when all we get is

•	set this record&#039;s status to ACTIVE PUBLISHED at Thu Nov 04 13:04:42 GMT 2010 
Notes: ACCEPTED 

The word ACCEPTED is not really a very clear way of informing people that this was from a user suggestion, it would be much better if the username or email address was included.

We therefore added
•	Notes: Suggestion via camdencouncil moderated by Lucy. 

2	Related Subjects on Search Results Page
This partially meets the case, although Magda did suggest a slightly different format for this as it was different to limiters – her suggested solution was to site the related subjects at the top of the results, in the centre.  As it is placed below the limiters it is not immediately helpful but it is in a similar place to the other subject guidance that would appear on subject search results.
It seems to only retrieve related subjects if you use one word, not a phrase, and that word appears in a used subject heading -  so single words like ‘Service’ gets Related subjects ‘Jury service’ etc but ‘Magic Arts’ does not retrieve other arts subjects. If there is a heading in the system eg Doctors, but no actual entries you do not get any guidance. This is the case Magda specified – we want headings that are not in use if they are steps in a hierarchy but more importantly we need our non-preferred terms so that we can get from GPs as a keyword to Doctors as a subject heading.

Thank again for the important progress this release includes for us.
Lucy</description>
		<content:encoded><![CDATA[<p>Hi, thanks for your work on pending suggestions and links to subjects &#8211; here is my immediate response. Looking forward to seeing the release here.</p>
<p>Response to 3rd November release preview</p>
<p>1	Pending suggestions for alteration</p>
<p>This worked well in the test site but we wonder if the Record History will show where the amendment came from. In the existing system we have to add a 2nd note when all we get is</p>
<p>•	set this record&#8217;s status to ACTIVE PUBLISHED at Thu Nov 04 13:04:42 GMT 2010<br />
Notes: ACCEPTED </p>
<p>The word ACCEPTED is not really a very clear way of informing people that this was from a user suggestion, it would be much better if the username or email address was included.</p>
<p>We therefore added<br />
•	Notes: Suggestion via camdencouncil moderated by Lucy. </p>
<p>2	Related Subjects on Search Results Page<br />
This partially meets the case, although Magda did suggest a slightly different format for this as it was different to limiters – her suggested solution was to site the related subjects at the top of the results, in the centre.  As it is placed below the limiters it is not immediately helpful but it is in a similar place to the other subject guidance that would appear on subject search results.<br />
It seems to only retrieve related subjects if you use one word, not a phrase, and that word appears in a used subject heading &#8211;  so single words like ‘Service’ gets Related subjects ‘Jury service’ etc but ‘Magic Arts’ does not retrieve other arts subjects. If there is a heading in the system eg Doctors, but no actual entries you do not get any guidance. This is the case Magda specified – we want headings that are not in use if they are steps in a hierarchy but more importantly we need our non-preferred terms so that we can get from GPs as a keyword to Doctors as a subject heading.</p>
<p>Thank again for the important progress this release includes for us.<br />
Lucy</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Talis Engage release to preview 6th October 2010 by Heather Spencer</title>
		<link>http://blogs.talis.com/engage/2010/10/08/talis-engage-release-to-preview-6th-october-2010/comment-page-1/#comment-89</link>
		<dc:creator>Heather Spencer</dc:creator>
		<pubDate>Thu, 14 Oct 2010 11:47:41 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.talis.com/engage/?p=542#comment-89</guid>
		<description>Some good features and improvements here. Here&#039;s the view from Lancashire:
Deleting Multiple Subjects - good. It&#039;s potentially dangerous that there&#039;s no longer a prompt about associated records but if taxonomy permissions are restricted to a small number of users this risk should be minimised.
Managing Pending Suggestions - increased flexibility in users&#039; permissions is good and we can really make us of this.
Deadlinks - better.
Advanced Searching - allow to search by last editor, brill! At the moment I can&#039;t see a need for selecting multiple usernames. Following on from Julian&#039;s comment, we would really like to see all our staff users able to search without specifying a term.
Performance - our calendar was really slow to load so this is an improvement.</description>
		<content:encoded><![CDATA[<p>Some good features and improvements here. Here&#8217;s the view from Lancashire:<br />
Deleting Multiple Subjects &#8211; good. It&#8217;s potentially dangerous that there&#8217;s no longer a prompt about associated records but if taxonomy permissions are restricted to a small number of users this risk should be minimised.<br />
Managing Pending Suggestions &#8211; increased flexibility in users&#8217; permissions is good and we can really make us of this.<br />
Deadlinks &#8211; better.<br />
Advanced Searching &#8211; allow to search by last editor, brill! At the moment I can&#8217;t see a need for selecting multiple usernames. Following on from Julian&#8217;s comment, we would really like to see all our staff users able to search without specifying a term.<br />
Performance &#8211; our calendar was really slow to load so this is an improvement.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Talis Engage release to preview 6th October 2010 by Julian Higman</title>
		<link>http://blogs.talis.com/engage/2010/10/08/talis-engage-release-to-preview-6th-october-2010/comment-page-1/#comment-86</link>
		<dc:creator>Julian Higman</dc:creator>
		<pubDate>Tue, 12 Oct 2010 14:09:32 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.talis.com/engage/?p=542#comment-86</guid>
		<description>Following feedback on the preview deployment, there are some amendments to the details above that should be noted:

When deleting subjects, the system will not currently display the number of associated records for each subject, which it used to do for individual subject deletions. This change was made as a side-effect of introducing bulk deletes, where the amount of information required to indicate associated records is much greater. However, we will look at adding this warning back into the system if users find it useful.

When using the Advanced Search to find records that were last edited by a specific username, users other than SysAdmin will need to specify a search term (with wildcards if required) as well as the username of the last editor. Only SysAdmins currently have the permissions to leave all search terms blank. This is something that we&#039;ll be changing in future releases unless there are scenarios that would make this inappropriate - let us know if you think so.

Apologies for these changes to the earlier details - we hope that none of them will be major blockers to using the system. Let us know if they raise issues that you need addressed in the next development cycle.</description>
		<content:encoded><![CDATA[<p>Following feedback on the preview deployment, there are some amendments to the details above that should be noted:</p>
<p>When deleting subjects, the system will not currently display the number of associated records for each subject, which it used to do for individual subject deletions. This change was made as a side-effect of introducing bulk deletes, where the amount of information required to indicate associated records is much greater. However, we will look at adding this warning back into the system if users find it useful.</p>
<p>When using the Advanced Search to find records that were last edited by a specific username, users other than SysAdmin will need to specify a search term (with wildcards if required) as well as the username of the last editor. Only SysAdmins currently have the permissions to leave all search terms blank. This is something that we&#8217;ll be changing in future releases unless there are scenarios that would make this inappropriate &#8211; let us know if you think so.</p>
<p>Apologies for these changes to the earlier details &#8211; we hope that none of them will be major blockers to using the system. Let us know if they raise issues that you need addressed in the next development cycle.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

