Screen Architect Prototyping Plug-in Released

[Bryce Day]

The team at Screen Architect are pleased to announce the release of Screen Architect version 1.0.

Screen Architect is a prototyping tool that plugs into EA and has been specifically developed to allow rapid prototyping of user interfaces.

For further information please visit the website www.screenarchitect.com

Regards
The Screen Architect Team

[bioform]

I installed the add-in and have just started looking at it...

I do notice that the response time on the add-in seems to be pretty slow on my laptop (P4 2.1, 1 GB mem, 256MB graphics card... maximum performance mode)...

So far, it appears interesting and worth me spending a little bit of time exploring it for a little bit...

Anyone else checking this out yet?

[AxNut]

You can launch and run the Screen Architect plugin either from within EA, or natively from your desktop. Using it natively performs a lot better

[bioform]

but that kinda negates the whole point of integrating it within EA?

Unless you mean launch it first, then EA?

[Jan Pacovsky]

Well the integration is still there - it still uses your EA model. It means that you can use the outputs from Screen Architect in your EA diagrams.

I've tried it (just a few minutes) and I like it, so far. It misses some quite frequently-used GUI elementes (eg. tabs) or element features (not active elements, checked check box or radio button), but i thing that the basic idea is cool.

[AxNut]

I guess apart from integration with EA, the really cool thing about Screen Architect is that one can generate HTML prototypes that can be walked / navigated through with end users.

[Martin Terreni]

It is cute tool.
The prototyping is a very good feature, but it laks of controls or avility to "create" them and it works very slow.
Right now we model our UI in EA (which does sertainly a good enough job) if SA had all .NET controls or avility to some how create them (and worked a little faster) no doubt it would be a tool with grate ROI (like EA is).

lookig foward to see it evolve.

[bioform]

Yes... having the UI components that we are used to, and increasing it's speed, would do a lot to reach a a purchase tipping point...

The one feature that stands out is the creation of an interactive "proto-type" with the integration into the EA project...

Good effort, but just not ready yet... IMO

DO NOT GIVE UP... (as I know you won't!), just consider the feedback (as I know you will!)

Best wishes, and I will keep the website on my Fav ToVisit list...

[Bryce Day]

Thanks for all the feedback, it is appreciated.

I have spoken/emailed with several of you since the release of Screen Architect about some of the improvements you would like to see.

Over this period we have been working on increasing the performance and are looking to release another version with this and a couple of minor enhancements to you shortly.

Seveal areas the team is interested in understanding more about are:
1. Types of controls - we have tabs, panels, grids and tables on the radar - are there others that are a must have?

2. Our aim has been to provide an integrated tool to allow wireframes and screen designs to be developed and prototyped quickly by the business analyst/interaction designer for use in the analysis & design phases. Several emails would like us to add enhancements in the code generation space.

How you see the Screen Architect being used? e.g. Screen design verses code generation and where is the greatest value to you and your organisation?

Thanks again and I look forward to the continued feedback
The Screen Architect Team

[jeshaw2]

How you see the Screen Architect being used? e.g. Screen design verses code generation and where is the greatest value to you and your organisation?

I normally work in the realm of CIM & PIM models with stakeholdrs.  When working with stakeholders, I am concerned about describing the look and feel of a System.  What you have is a good start on the look of a GUI, but I've not yet found the feel part.

At the risk of promoting Executable UML (a disciplined place I'm not currently ready to go with Business & Requirements Analysts), I might suggest that you think about finding a way to:

• integrate into the mix a Protocol State Chart--as a link back to the Use Cases partially realized by the GUI; and
• provide a way to incorporate scenario demonstration with representative domain data, all under control of the Use Case Protocol.

This provision of the feel would of great value in driving out heretofore unarticulated Requirements.

[Jan Pacovsky]

How you see the Screen Architect being used? e.g. Screen design verses code generation and where is the greatest value to you and your organisation?

The best benefit is the ability to create prototype by business analyst very quickly. The "feel" part of application is very often defined by design manual of our customer - so that I don't need improvements in this way.

It would be great if the screen architect could generate screen flow from links defined between screens (lets say buttons only for example).

Regarding code generation features - we don't need it. :-)

[jeshaw2]

Seveal areas the team is interested in understanding more about are:
1. Types of controls - we have tabs, panels, grids and tables on the radar - are there others that are a must have?

My thoughts would be:

• A named Element group to associate/differentiate/contain multiple sets of radio buttons;
• Menu bar & drop down Sub menu;
• Window boarder & title bar
• Frame sets for web enabled forms (perhaps as a specialization of panel?)
• Hot spot buttons (transparent buttons with dotted or dashed outlines that sit over interesting points on an underlying/background image.  Not all stakeholders on a manufacturing shop floor are able to read.  What would be really cool would be the ability to draw a polygon shaped button, but I don't know how to implement that in code.
• Element attributes such as isLocked, isVisible, default value, etc.  This would feed into the state diagram transition logic.
  

I'm excited about the ability to link/embed your screen designs to EA models, but I need more to pull me away from the type of tools I currently use.  At present I use a mix of:

• Story boarding to demonstrate state changes, followed by
• a proof of concept mock up using the forms capability and simple scenario tables in MS Access (just enough to give a feel of the form's behavior), and finally
• the IDEs provided by Visual Studio and/or Net Beans.

For me, the priority is with the client facing aspects of Requirements Specification rather than with the speedy generation of code that provides incorrect behavior.  While our developers have input on tool selection, it is the Project Managers and Technology Managers that make the final tool selections;  and, they do that work at the front end of the project, not in the middle where the development team kicks in on a project.

Another big factor in tool selection are the concerns of IT Business Analyst and Solution Architects (both of whom probably have programming as a distant career base) who will be the first on the project to use these tools.  They will be most concerned with a system's Cognitive Design, Navigational issues, and Use Case Protocols.  I'm looking first for tools to support resolution of those issues, and when we get that correct, then I'll be happy to talk you about code generation.

Good luck.  You've got a great start on a great idea!  Keep on slogging.

Jim

[Graham_Moir]

The scope of this is snowballing very quickly, so
my vote is to try and contain it with Jan's view of the world.

Perhaps 1.x releases can concentrate on streamlining the prototyping aspect including the ability to navigate between screens, and version 2.0 can start the code generation side of things

[bioform]

The scope of this is snowballing very quickly, so
my vote is to try and contain it with Jan's view of the world.

I agree... don't try to be EVERYTHING... focus on one aspect of your vision for this project, then make it robust (through small interations in my opinion...)

I think the prototyping aspect has the most bang for your development buck... as there are other tools for doing the code generation... and besides, if I can't prototype the screens to reflect WHAT I want them to be... then WHY would I spend the time turning them into code so I can execute screens that does not meet my customer's needs?

Looking forward to future releases...

[Martin Terreni]

1. Types of controls - we have tabs, panels, grids and tables on the radar - are there others that are a must have?

Whatever is in VS

2. Our aim has been to provide an integrated tool to allow wireframes and screen designs to be developed and prototyped quickly by the business analyst/interaction designer for use in the analysis & design phases. Several emails would like us to add enhancements in the code generation space.

How you see the Screen Architect being used? e.g. Screen design verses code generation and where is the greatest value to you and your organisation?

I'm the system architect (not technical architect) and my main concern is to fit customers functionality request, so code generation for me is less important, yet I do work tightly with the technical architect and in order to have full traceability from design to code I would like your tool to create from my design in the tool the relevant objects in EA(EA does have UI objects I use to design the UI) so all the design indeed stays in the same repository and maybe in the future I'll be able to generate ALL code from within EA (both EA part and SA part).

Also I agree that whatever is goign on here had turn in to a snow ball...

thanks for letting us participate.