Actions

Difference between revisions of "Proposals/Done/Views"

From Mahara Wiki

< Proposals‎ | Done
Line 35: Line 35:
 
** View – Add Tutor Access
 
** View – Add Tutor Access
  
[[Image:=access_control.png|access_control.png]]
+
[[Image:access_control.png|access_control.png]]
  
 
</div></div></div><div class="t-title"><div id="section_4">
 
</div></div></div><div class="t-title"><div id="section_4">
Line 48: Line 48:
 
e.g. Profile Icons, Goals, Skills, Professional Memberships,  – all just another block type<br />     e.g. Education History block or add title to text block afterall<br /><br /> Impact is that Resume then just becomes another scaffold/template<br /> Create new , Update for all Views <br /><br /> The problem I see with the form builder approach is that it introduces a different mechanism from the core View building approach. We should aim for consistency in content management.
 
e.g. Profile Icons, Goals, Skills, Professional Memberships,  – all just another block type<br />     e.g. Education History block or add title to text block afterall<br /><br /> Impact is that Resume then just becomes another scaffold/template<br /> Create new , Update for all Views <br /><br /> The problem I see with the form builder approach is that it introduces a different mechanism from the core View building approach. We should aim for consistency in content management.
  
[[Image:=inline_editting.png|inline_editting.png]]
+
[[Image:inline_editting.png|inline_editting.png]]
  
 
<div class="t-title"><div id="section_5">
 
<div class="t-title"><div id="section_5">
Line 64: Line 64:
 
Profile, Resume Folder
 
Profile, Resume Folder
  
<br />[[Image:=folder_inline.png|folder_inline.png]]
+
<br />[[Image:folder_inline.png|folder_inline.png]]
  
 
<div class="t-title"><div id="section_6">
 
<div class="t-title"><div id="section_6">
Line 85: Line 85:
 
</div></div><div id="page-top"><div id="pageText" class="pageText">
 
</div></div><div id="page-top"><div id="pageText" class="pageText">
  
[[Image:=social_history.png|social_history.png]]
+
[[Image:social_history.png|social_history.png]]
  
 
</div><div id="pageText" class="pageText"><div class="t-title"><div id="section_8">
 
</div><div id="pageText" class="pageText"><div class="t-title"><div id="section_8">
Line 93: Line 93:
 
</div></div><div id="pageText" class="pageText"> </div>
 
</div></div><div id="pageText" class="pageText"> </div>
  
[[Image:=my_views.png|my_views.png]]
+
[[Image:my_views.png|my_views.png]]
  
 
</div></div>
 
</div></div>

Revision as of 18:44, 12 May 2011

Discuss this topic

Functionality underway in version 1.3

3.2 Print

  • Improve the Print function to strip ancillary content and keep the View layout.
  • Download as PDF (this can be done with sites such as LinkedIn – how achievable?)

3.3 Improvements to Access Control


  • Editing access rights for multiple views (also when they are not under one heading) more easily. Development underway in Version 1.3
  • Use the Friends List function to create Access Lists, Friends List 2? Access Lists in effect, name Friends List?
  • Tutors/Teachers (business rule – staff from institution and/or groups I belong to). Selector like Moodle?
  • Groups (business rule – only groups that I belong to) Selector like Moodle?
  • What about a Moodle-like boxes:
    • View – Add Group Access
    • View – Add Tutor Access

access_control.png

3.4 Extended Inline Editing to include Profile and Resume fields or… Form Builder?

  • Resume could simply be a View Template
  • Inline editing to include Profile fields and Resume fields profile fields

e.g. Profile Icons, Goals, Skills, Professional Memberships,  – all just another block type
    e.g. Education History block or add title to text block afterall

Impact is that Resume then just becomes another scaffold/template
Create new , Update for all Views

The problem I see with the form builder approach is that it introduces a different mechanism from the core View building approach. We should aim for consistency in content management.

inline_editting.png

3.4.1 Default folders to support Inline editing

Default folders cannot be deleted.

Content within default folders can be deleted.

e.g.

Profile, Resume Folder


folder_inline.png

3.5 View Templates

  • Extension of View Types with ability to add View Type e.g. Resume is a Template – has the scaffolding but not the content.
  • Well designed themes/ borders to select from.
  • Template scaffolding should support different files as empty shells
  • Save as Template – Admin function only. Would mean that scaffolding is saved with headings and content type but no content.


Options: Could be located as a selector in the My View List or in the Create View dashboard:

3.5.1 Option 1 templates accessed via My Views

social_history.png

3.5.2 Option 2 Templates as part of the Edit View interface

 

my_views.png

Files

  • Access control.png
  • Folder inline.png
  • Inline editting.png
  • My views.png
  • Social history.png