Posts Tagged ‘widget’

Reflex Feedback 0.3

A small update to the Reflex Feedback Widget,

  • Design tweaks (border, box-shadow, border-radius on textarea; padding-top on copyright)
  • widgetPos argument added to init(), valid values => ‘left’, ‘right’

reflex feedback widget 0.3

So you can now position the widget on the right edge of the page like this:

Reflex.init($('body'), 'controller/post_feedback.php', 'right');

More info about the widget itself can be found in the original blog post.

Reflex Feedback 0.2

An updated version of the Reflex Feedback widget is now up.

Changes:

  • New icons done by myself and released under the same license as the code; no longer using the ones by Yusuke Kamiyamane. This should also make it easier for those who want to do custom modifications as they don’t have to worry about an attribution requirement for the icons.
  • New menu layout and new buttons. Now using jQuery UI buttons for everything, which allows for compatibility with jQuery UI styling, ThemeRoller, etc.
  • CSS fixes to prevent some inherited styles from screwing up layout.

reflex feedback widget

For info on how to use the widget, see my original post on Reflex Feedback.

Mojo.Widget.ImageView

Using the ImageView widget is somewhat perplexing. The documentation states:

This widget is designed to view an image full screen with support for zooming and panning…

You would assume that you could simply create the ImageView widget and it would be full screen and handle orientation changes (something very essential and common when viewing photos) out of the box. Unfortunately, this is not the case and some additional code is necessary to get it to function as such.

dotspott photo view

I’ll present some code here, but much of what I did was based on the code at webOS 101.

First, a few additions to the assistant’s activate function:

  • We setup full-screen mode
  • Set “free” orientation (allows the system to rotate the display)
  • Manually size the ImageView widget (id=photoView)
ViewPhotoAssistant.prototype.activate = function(event) {

    
this.controller.enableFullScreenMode(true);
    
this.controller.stageController.setWindowOrientation('free');
$(
'photoView').mojo.manualSize(Mojo.Environment.DeviceInfo.screenWidth, Mojo.Environment.DeviceInfo.screenHeight);

    
/* set images here */
    
};

To actually respond to orientation changes we need to setup an event listener for the “resize” event. This is dealt with in the assistant’s setup function:

ViewPhotoAssistant.prototype.setup = function() {
    
    
var photoViewerAttributes = { noExtractFS: true };
var photoViewerModel = {};

    
this.controller.setupWidget('photoView', photoViewerAttributes, photoViewerModel);
    
    
// setup handler for resize event ...
    
this.handleWindowResizeHandler = this.handleWindowResize.bindAsEventListener(this);
    
this.controller.listen(this.controller.window, 'resize', this.handleWindowResizeHandler);

/* other setup code... */

};

Within the resize event handler, we manually resize the ImageView widget based on the new dimensions of the window:

ViewPhotoAssistant.prototype.handleWindowResize = function (event){
if ($('photoView') && $('photoView').mojo) {
        $(
'photoView').mojo.manualSize(this.controller.window.innerWidth, this.controller.window.innerHeight);
}
}

Finally, in the assistant’s cleanup function, we stop listening on the event:

ViewPhotoAssistant.prototype.cleanup = function(event) {

    
this.controller.stopListening(this.controller.window, 'resize', this.handleWindowResizeHandler);    

};

Reflex Feedback widget

I worked on a small AJAX widget for user feedback built atop jQuery UI: Reflex Feedback. It’s inspired by the widgets you see from services like Get Satisfaction and UserVoice, but much simpler and it’s a frontend-only widget, how you handle the feedback info on the backend is up to you.

Here’s what it looks like.

reflex feedback widget dialog

And here’s what the tag that opens the dialog looks like:

reflex feedback widget tag

To use it, download or clone the ReflexFeedback repo from bitbucket

Place the .js file wherever you’d like but the /reflex.content folder should a subdirectory in the same folder as the page loading the .js file. Load reflex.js as you would any other javascript file:

<script type="text/javascript" src="js/reflex.js"></script>

Call Reflex.init() to add the widget to the page. The first argument is the DOM element to attach the additional HTML/CSS code to. The seconds argument is the server-side script to call when the user clicks Send Feedback.

Reflex.init($('body'), 'controller/post_feedback.php');

That’s it for the frontend. You should see the tag show up in the right-hand corner and when clicked the dialog open.

For the backend, the AJAX call to send the feedback info will send a POST request with 2 fields: feedback_type, feedback_txt.

Reflex expects an XML reply from the server:

<reflex>
<result>ok</result>
</reflex>

ok indicates a successful result, any other reply is considered an error.

A successful result will close the dialog and show another with a thank you message.

reflex feedback thank you dialog

For an error, a message is shown below the Send Feedback button, informing the user that an error has occurred and to try again.

reflex feedback send fail

As for what to actually do with the feedback, that’s up to you, but what I’m doing is sending myself an email with the feedback info. I’ve posted my PHP script below; feel free to use it, modify it, etc. If you do use this code, be sure to fill in your mail server credentials and a from address; you’ll also need PEAR’s Mail package installed.

<?php

require_once "Mail.php";
require_once "Mail/mime.php";

header('Content-type: application/xml; charset=utf-8');
echo "<?xml version=\"1.0\" encoding=\"utf-8\"?>\r\n";

if(!isset($_POST['feedback_type']) || !isset($_POST['feedback_txt']))
{
echo "<reflex><result>error:missing-arguments</result></reflex>";
}
else
{
$from = "...";
$to = "...";
$subject = "Feedback from user...";

$feedback_type = $_POST['feedback_type'];
$feedback_txt = $_POST['feedback_txt'];

$bodyHtml = "<html><body>";
$bodyHtml .= "<p>Type: {$feedback_type}</p>";
$bodyHtml .= "<p>Feedback: {$feedback_txt}</p>";
$bodyHtml .= "</body></html>";
$body = $bodyHtml;

$host = "...";
$port = "...";
$username = "...";
$password = "...";

$headers = array('MIME-Version' => '1.0rn',
'Content-type' => 'text/html; charset=utf-8',
'From' => $from, 'To' => $to, 'Subject' => $subject);


$smtp = Mail::factory('smtp',
array ('host' => $host,
'port' => $port,
'auth' => true,
'username' => $username,
'password' => $password));

$mail = $smtp->send($to, $headers, $body);

if (PEAR::isError($mail))
{
$err_details = $mail->getMessage();
echo "<reflex><result>error:send-failure</result><details>{$err_details}</details></reflex>";
}
else
{
echo "<reflex><result>ok</result></reflex>";
}
}

?>

That’s all for now. I’ll work on more features and options for customization in the future. You can see the widget in action over at dotspott.com

Enyo

I missed webOS Developer Day, but I took a look at the presentation of the Enyo framework (video below). I like most of the bullet points: faster performance, hardware acceleration built-in, etc. However, one point that’s troubling me is the idea of using higher-level controls instead of divs. From the bit of code presented in the final demo, it looks like layout (and pretty much all UI stuff) will be done using JavaScript widgets, which are translated at some point into the appropriate HTML constructs. Obviously, widget-centered development isn’t a new concept (MFC, WinForms, Cocoa… sproutcore and such on the web) nor is it necessarily a bad one (getting something presentable up and running is easier), but there always seems to be a very real and very large loss of flexibility.

When a widget doesn’t look or function exactly how you need it to, and it becomes necessary to make a new one, development within the widget framework can range in difficulty from trivial to near-impossible. As I mentioned when I wrote about Adobe Air, HTML/CSS isn’t perfect, but it’s the most flexible layout and styling framework I’ve come across. Abstracting away that flexibility in favor of plug-and-play widgets makes me cringe… it’s a nice idea, it’s a very (object-oriented) developer-ish idea, but it usually comes with a pretty high cost.

From working with both HTML/CSS and WinForms extensively, I’d say the widget-centered framework model used for desktop apps shouldn’t be replicated for web development. In fact, it should be the other way around: the flexibility of a HTML/CSS-esque system should be brought to the desktop.

How this will play out for Enyo, I don’t know. I’m cautiously optimistic. Being a web framework, everything still boils down to HTML and CSS, but it remains to be seen what level of manipulation will be allowed or make sense (in terms of performance, coding difficultly, etc.) at that level.