Preserved Topic: World's Tallest Digital Building (Page 2 of 2)

Make that 3.

4

___________________
Emps

The Emperor dot org

flash's all right.
Just holler when you get to the server side side.
Oh, SVG would be nice as well, but oh well, no one has the plugin anyway.

Well, hopefully we can make the server side part of this generic enough (xml) that we could make several different display clients for it if anyone saw the need for such a thing. I would have suggested SVG and Java as possible solutions but I know very little about those technologies.

Ah,,,, the happy gurglings of Mad Scientists at work, don't you just love it?
I have no idea of most of what's said, but that's my loss.
tao

This sounds like a good use for Flash, so another vote here.

_________________________
"There are 10 kinds of people; those who know binary, those who don't and those who start counting at zero"
- the Golden Ratio -

I really dislike Flash... but I really like this concept and want to see it happen regardless of the technology used

. . : slicePuzzle

Why not something like this :



And, I'm really not for Flash. (D)HTML + PHP can do exactly the same job.
EDIT: sorry for the ugliness (?) of the sketch

Mathieu "POÏ" HENRI

[This message has been edited by poi (edited 12-21-2003).]

i hope no one minds but, i started a faq specifically for pixel art since there wasn't one. :FAQ: Pixel Art

[This message has been edited by Lacuna (edited 12-21-2003).]

oh, that's coming along nicely...good job on the scetch

Indeed, this could be done using a number of different technologies. But having worked with both (although, I'm not on par with you when it comes to DHTML), for what I've currently got in mind I believe flash would be a better choice.

But that's not to say we can't have multiple clients to display this data with. If the backend is created with this in mind then it would be interesting to see different people making different clients to display the data with. After all, having more than one person programming the client side of things is going to be overkill and cause confusion anyhow.

If we can come up with some ideas of how to standardize the backend interface and how all of this data will be stored and related to the members database of TP's Grail asylum, then I don't see how this would cause any problems. Indeed it would be interesting to see a project like this where different technologies use the same data to create different displays. Although, my only fear with this is that by standardising everything to be as flexable as possible the end products made end up being rather "canned" and limited as a result.

To develop a little my argument against Flash I'd say it has ( except MX or MX 2004 ) that little bug when displaying bitmap images that double some lines and disalign (?) the images and make them "pop" when they are moving. Unless you do it by hand, you don't see the URL of the elements your hover in the status bar, neither you can copy the location or open them in another Tab or Window in case you'd like to see several cells at a time.

For the data input interface, the easiest way could be to add a "pixel-cell" field in the "inmate" table.
When an inmate edit his/her profile ( or cell if you prefer ), he/she can download the pixel-cell template ( in a .ZIP in various formats ( .PSD, .GIF, .PNG, ... ) ) and upload/update his/her final pixel-cell image, and voilà.

EDIT: Since it's already the case with the monthly sig contest on the Grail, the pixel-cells could be stored on the Asylum itselft to lower the number of attacks by the Red Cross Monster.

For the front end, we could do something the famous navigation bar where you simply have to move your mouse close to the border of the content area to make it scroll. The scroll would obviously follow the slope of the isometric tiles. The only problem we could encounter is to load the infos of the cells if the user scroll like crazy, but nothing we can't handle. The template cell can be displayed until the pixel-cell / cell number / nickmane are loaded. And when the user do not scroll, nothing forbids us to preload the infos of the sibling cells.

Cheers,

Mathieu "POÏ" HENRI

[This message has been edited by poi (edited 12-22-2003).]

Ok, I really don't want to turn this into a Flash vs DHTML thread, so I'll be breif. There are ways around all of those issues, but I'd question why you'd want to support some of those things anyhow. I've always been of the belif that you should design for the user, not for the medium.

The bitmap shifting issue only happens when you do motions tweens, if you code the animation and restirct the movement to integers then you simply won't have that problem. As for being able to see the URL -- I was thinking one HTML page would be sufficent regardless of the technology, which means there's no need for such a thing. As for being able to open things in a new window -- I don't see how this has anything to do with the application's primary goals as I see no reason why a user would want this to be displayed in multiple windows period. Even if they did, all they need to do is open an new window and cut-n-paste the URL from the previous browser window, but like I said, I don't see any need for someone to do this.

As for the actualy display, I was approaching this in slightly more of a "tower" format as that's what the majority in here seemed to want, perhaps with several cells per level. Or a more freeform format similar to your sketch but with the cells tiling in 2 directions instead of just one with actual hallways being generated to join them togther where needed. I like your idea, and indeed this would be expressly simple in DHTML, but I think it's a little too linear. Isometrics offer the ability to tile each cell in multiple dimensions and I think it would be a waste to ignore this:



But I really didn't want to be tossing around images at this point. I think there's a lot more to be considered then the technology and the interface for this. I'm also quite tied up with other projects for another week or so and thus can't devote much headspace to thinking this over right now.

[This message has been edited by Cameron (edited 12-23-2003).]

We do have a lot to do if this is ever going to happen and if it is doable in Flash then I think we should pursue that path for the moment but, if it is possible, it would be worth going the extra mile so that a DHTML interface could be added on at a later date.

I think at the moment we need to focus on the look, etc. - I'd love to hear what mahjqa thinks of this for starters.

Cam: Love the Escher look - is it possible to extend that in various directions though?

___________________
Emps

The Emperor dot org

Given that a lot of us come to the Asylum to learn about technologies like DHTML, CSS, javascript, etc. my vote would be to use those same technologies so that this might be an example of what can be done and a learning experience for all involved.

Of course, maybe there are a lot of Flash developers on this forum, so Flash may be appealing. (I'm showing my bias here as I am not a Flash programmer...)

MF: But it isn't an either/or situation - we should be able to do both but to get things moving in one direction I think we need to select one and develop things on that front and then work on adding another interface.

___________________
Emps

The Emperor dot org

Looking at the backend...

Since it will be tied in with the grail, this will undoubtably be PHP, and the great thing about using PHP is that we can actually put a number of front ends onto the one backend and let people choose what they want.

I say we draw up a list of specs for the front end, then we give the development of the various mediums (DHTML, Flash, etc) over to different people. Those peole can then recruit the group that will assist them in the development of their front end. Meanwhile, there will be another group of us working on the backend, getting it to output to a common format that all of the various front ends can read (most likely XML).

As my I.T Teacher at high school used to say "Get it working, then make it look good"

Skaarjj, sounds like a plan, but...

First we need to decide on exactly what we want this to accomplish and what we'll need to do that. I'm not talking about just saying, do the back-end with PHP and the frot end with x, y or z. Starting a project by making a decision about the technology before you know exactly what your doing isn't a good way to start. Know the technology helps, but there's still a bit of pen'n'paper work to do if this is going to work well.

If everyone involved has a different concept as to how this will pan out, it'll cause lots of wasted time and people (the developers) will start to loose interest and cut corners. I've seen this happen a lot and would like to avoid it if at all possible.

I'll write up some stuff to get things started over the next few hours and start up a thread in the MS forum under the heading Cellular Asylum.

[This message has been edited by Cameron (edited 12-23-2003).]

quote:

---

I've always been of the belif that you should design for the user, not for the medium.

---

That's why I'd rather go for DHTML to let the user use all the built in features of the browser ( all the things like showing an URL in the status bar, all the functions in the contextual menu, the Ctrl+click to open a link in a new tab, copy/paste ... ) vanished by Flash.

When I talked about opening several windows, I meant that a visitor could browse the Asylum building a.k.a the front end ( in a page in the vein of the World's Tallest Digital Building ) and wish to see the profile/cell of some inmates ( in a new tab/window ) but keep browsing the Asylum building in case he/she sees another pixel-cell that please his/her eyes and wish to see the profile/cell of that other inmate, and so on...

Add to that that if the user do what you said, that is to open a new window and copy/paste the URL of the Asylum building, he/she'll have to scroll a lot to get back to the place where he/she was in the original window.

As for the visual approach to browse the Asylum building, I did my sketch like a corridor 'coz real asylums are more like corridors ( that's why we talk about east/west wing, no ? ) rather than towers, but I don't really care

Regarding the needs, as I said in my previous post, all we need in the back-end is a text field in the inmates table to store the name of the pixel-cell image uploaded by them ( which will be replaced by cell_number.file_type ( file_type being GIF, PNG, JPG ... ) to avoid name conflicts ). Nothing more, nothing less. The upload process could check the resolution of the new image and decline it if it's to big or saved in an invalid format.

Skaarj: If we follow the advice of your teacher, it's just a matter of few hours to make a working back-end and front-end. Really. The core of this thing is extremely basic ( let the inmates upload a pic. display a list of these pics with a link to their cell/profile ), but that's how we'll make the front end interface that matters. Whatever, I'm all to make the things quick, and don't bear to waste my time. I've wasted enough time at work.

Below are several tests to see how we could stack the pixel-cells :



My preference goes to B1, C1 or D2 because in the others some cells are partially/completely hidden. D2 seems to be the most practical and we could eventually insert some small corridors between the cells, and use the left ones as the west wing, right ones as the east wing, and the middle ones as the Mad Scientists wing.

Cameron: What do you have in mind for the front-end that would require the use of Flash ?

Mathieu "POÏ" HENRI

*Sigh*? Why would I want to use flash? Why would you want to use DHTML?

These questions could be asked till the cows come home and none of us would end up with a satisfactory answer. You can nit pick at specific features all you want but at the end of that day, as long as the application is functional and achieves it's goals, it really doesn't matter what technology you use. My main arguments for using flash are its stronger animation capabilities and the ability to perform server side calls and database queries without having to load another page, thus we could just load the users profile directly from the application without needing to send them to another page to show that information. Along with a list of other things that would just be a pain to try and support in DHTML.

In all honesty, I shouldn't have asked the question about what technology would be used for the client interface as this just saw people making rash assumption about the final outcome of the project, which is what I wanted to avoid.

quote:

---

let the inmates upload a pic. display a list of these pics with a link to their cell/profile

---

That's exactly the reason I didn't want to jump in head first. I think this can be a lot more than just that but obviously no one agrees with me and I really don't have the time nor the energy to argue this right now so go ahead. I have plenty of other things to do anyhow.

quote:

---

*Sigh*? Why would I want to use flash? Why would you want to use DHTML?

These questions could be asked till the cows come home and none of us would end up with a satisfactory answer.

---

I didn't meant to tease, but wanted to hear how you see the front-end to think that Flash is more appropriate than DHTML. What do you wish to animate, and how ?

Remote scripting or writing a new <script> tag is common place. It's not a surprise but I tend to think that unless what you wanna do with Flash is impossible or source of a lot of headache to do in DHTML, you must do it in DHTML to keep all the built-in functionnalities of the browsers the users are used to use ( remind me to use the word "use" less in 2004 ).

I hope you, and some other inmates , could take some time to explain what you see for the whole thing.
Till then, have a Merry Christmas.

Mathieu "POÏ" HENRI

ok...besides the beytter animation features and such, another argument the (in my opinion) puts flash over DHTML in this discussion? Flash is equally supported (almost) across the board. When you do something in flahs, it works the same whether it's in IE, netscape, mozilla, etc. OYu know if it works in one it's going to work in the other. DHTML on the other hand doesn't work like this. Unfortunatly

I'm still unsure what the discussion is over really - Cameron has offered to give it a shot and if it works out we can add a DHTML interface. As I said:

quote:

---

But it isn't an either/or situation

---

What we really need now are examples of floorplans, etc. to get an idea of the range of possibilities (we already have some but lets see some more).

___________________
Emps

The Emperor dot org

I am with Emps on this one. Flash or DHTML doesn't matter. Make a robust backend that will be extendable into a multitude of front ends, and then design your front end with your favorite tool. Just make sure to stay away from hard coding the data into the front end application. I am under the impression the Flash has the excellent ability of interworking with PHP, as do most web formats. Neither flash nor dhtml (is it even called that anymore? EMCAScript or something?) is completely supported. So work on making a good PHP backend (flash can link to php can't it?) and publish the API, we will have no problems modifying it to fit the individual needs.

-Dan-

WM: Agreed.

quote:

---

flash can link to php can't it?

---

Yep in a multitude of ways (XML, remoting or just loading text strings).

___________________
Emps

The Emperor dot org

Another thought that could tie into this would be to attach a chart to each room with the resident of the cells 'diagnosis' along with comments left by other doctors or wandering inmates. Each cell could have its own chart with some autobiographical and external info, dosages, pictures, etc.

#cough#

#cough# indeed. So tell me people...are we agreed on PHP as the backend for this? If we are we can start to nominate people to lead the various working groups for the different elements: backend IDE, flash frontend, DHTML frontend, overall design concepts and so on and those people can then get on with recruiting their groups to help them.

So...are we agreed?