Jump to content

Attachment system improvements


Guest Digi

Recommended Posts

I wanted to make a separate topic because my thoughts got a bit lost in the "multiple attachments" one. Please don't turn this in to a multiple attahcment topic, it's been beat down to a pulp (post here if you must). These suggestions focus on improving usablity, not only adding multiple attachment support (though it seeks to improve that as well, in time). Let me know what you think!

And just to be clear, I'm not fighting improvements on usability to this module. I think it needs it. I also think a lot of IPB is too reliant on javascript and CSS for display (because of this it also adds a lot of "necessary" (x)html) which hurts the ability to digress or even properly redesign for nont-xhtml displays, like WAP (this module is one of the worst in this case).



What I would really like to see is:


[list=1] [*]The attachment area should degrade to a single [i]file input[/i] field when javascript is not present. Logic should be in place to prevent the appearance of the [i]upload button[/i] when javascript isn't available (i.e. javascript should actually create the button). This button should also use xhtml's form input type "button" or "image" for accessibility, standard compliant reasons (will make your js easier too :P ), and simply semantic reasons. [*]Upon [i]upload[/i] (pressing the upload button), and after javascript validation against the attachment passes, the file input should be immediately hidden and the attachment added to the area mentioned in item 3. The file input should be replaced immediately with a new one for further inclusion of attachments. [*]Remove the javascript dropdown thing that contains attachments and move back to each attachment being visible on screen during the process. This [i]area[/i] could be made scrollable if preserving screen space is important, but personally I think the scrolling would cause it's own usability issues (just like the drop down does). The best method (to prevent screen location alteration upon submit) would be to add the attachment list [b]after[/b] the attachment form (screen won't [b]jump[/b] this way unless a new scrollbar is added like it did pre-current system), and in reverse order of uploads so that the last upload made is always on top. [*]For each attachment that is processing a status indicator should be present. Until upload progress indication is possible, you could use the "please wait" swirly thing you have now to denote that it is in progress of some sort. When the ability to reliably track progression is available, this should be replaced with a status indication of said progress. In both cases, when the upload has completed [b]successfully[/b] it should show this blatantly. On error, the ability to simply "re-upload" should be available in addition to delete. [*]Topic reply form should be disabled from submitting until all uploads are complete. Indication (through humanized text) that this is the case should be extremely visible otherwise users will get frustrated easily. [*]And, for technical considerations when the multi-uploads is present (js is available), consider the use of object to replace iframe (also going to make it easier for you to control the display of without so many hacks ;) ). However, I understand this may not work as expected given the nature of the beast.


Link to comment
Share on other sites

i see a contradiction of terms here digi, firstly you say that ipb is too dependant on javascript but most your suggestions involve adding even more complex javascript?



It's not a contradiction. Being too dependant is that it actually requires javascript to operate at all (currently). This revamp will require slightly more javascript for the "fancy" components, but no javascript for general operation. And, frankly, there's only one addition to the javascript component in that it must create the iframe/object to override the default single, inline, upload field (also creating the upload button) in order to maintain no javascript functionality....or...in some user's cases....to make it easier to remove javascript component all together in place of something else like flash, java, or silverlight components. Everything else I asked to be changed with the system already works in similar ways and already needs the javascript. This suggestion seeks to componentize the "fancy" javascript form for accessibility, usability, and expandability. ;)
Link to comment
Share on other sites

Biggest problem for me is most of the attachments at my site are for images. There's no way to restrict resolution or file size by image type. It should be just the same as the gallery where you have file type specific maximums. I have to allow bigger attachments as some files are zips and these can be up to 2mb in size.

3DKiwi

Link to comment
Share on other sites

I'll put in my 2c for the attachment drop down, I personally dislike it.
I'm not sure why it was done that way (i'm sure there was a reason), but I would like it to be considered to go back to the old way where it shows all the attachments without having to click something to show them. 2.1 I think as someone mentioned had it.
As many people think, a majority of posts will have ONE attachment anyway.

Link to comment
Share on other sites

yea i believe the attachment system could do with a interface update and yes ipb should be using hijax solutions on all its js parts but personally i always have js enabled as do many people so the low fi version isn't going to be a issue or a interest to me, i doubt i'll ever even see it.

Link to comment
Share on other sites

  • 5 weeks later...

I think two functions are important hee

1. multiple and automatically-created uploaded folder of images

2. allow to attach files into completely different server

IPB claims itself for LARGE firm use, but tries to SATIN all images under one folder for what reasons?

we have 60K members and if we start allowing them to upload images, can you imagine that?

Link to comment
Share on other sites

I think two functions are important hee



1. multiple and automatically-created uploaded folder of images



2. allow to attach files into completely different server



IPB claims itself for LARGE firm use, but tries to SATIN all images under one folder for what reasons?



we have 60K members and if we start allowing them to upload images, can you imagine that?



IPB already creates monthly storage folders for attachments (as of 2.2.x or 2.3.x, can't recall). It no longer stores all attachments under one folder.
Link to comment
Share on other sites

  • 1 month later...

I think two functions are important here


1. multiple and automatically-created uploaded folder of images


2. allow to attach files into completely different server


IPB claims itself for LARGE firm use, but tries to SATIN all images under one folder for what reasons?


we have 60K members and if we start allowing them to upload images, can you imagine that?


IPB already creates monthly storage folders for attachments (as of 2.2.x or 2.3.x, can't recall). It no longer stores all attachments under one folder.


One of my sites has a bit over 170,000 photo attachments, even after pruning and archiving posts over one year old. We faithfully upgraded all the way from 1.5 up to IPB 2.3.1
The photos still all store in the one 'uploads' folder. It does not make monthly for us. We reduced load on one server by using a second server and simply linking that upload folder in a tunnel to it. The forum server simply 'thinks' it is a normal folder on there.

I agree with everything Digi has mentioned here. His hints and ideas allowed a hired programmer to modify and improve our present version. I would especially like to see this corrected in the present attachment system for use with wap also. It would be a real plus if members could use their cellphones or pda's and upload photos and/or videos directly from that as well.
As photos and videos are the most important item in a forum that is not being used as a BBS, The attachment area, and in fact the entire site, should have a true PDA interface. If this were in place, and it worked on a cell phone, imagine how much better it would be on a PC connect.
Like running a dos written program on a Vista machine executes like lightning. Perhaps going back to what worked and tweaking that to perfection is a solution. Like oldversion.com says, "because newer is not always better"

I believe Digi's ideas could drastically enhance many areas of the attachments, fullfilling different needs of different customers. I know I would consider rejoining the paid customer area to gain a new and improved version of IPB if it included this.
Link to comment
Share on other sites

  • 4 weeks later...

Honestly.. I completely agree with Digi. I think the attachment system needs to be simplified more, and degradable if javascript is not present.

But I don't think java script should be necessarily the main component behind the uploading process, but more like the glue that connects the pieces together. JS just isn't robust enough by itself for uploads, mainly because you have to rely to cross-browser compatibility.. I've seen much better support for uploading files in Flash... And most people have it anyways.. And if they don't, they can upload one file at a time, or download flash. Plus flash has the ability to control file type selection, file size (before upload), etc...

SWFUpload is a great example of how this is possible: http://swfupload.org/

They have an API that you can build into. I'm thinking about implementing this myself in some sites I'm working on, but haven't quite gotten to that part in our development cycle. But it looks promising!

Personally, I'm all about improving quality and usability, what ever that happens to be in. Multiple uploads is not something "I must have" because frankly I'm no longer caring about features I want anymore. I think that happened shortly after I decided to not mod my board and the "default" was good enough for me :).

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...